因为MySQL选错索引导致的线上慢查询事故

mysql视频教程栏目为大家介绍MySQL选错索引导致的线上慢查询事故

前言

又和大家见面了！又两周过去了，我的云笔记里又多了几篇写了一半的文章草稿。有的是因为质量没有达到预期还准备再加点内容，有的则完全是一个灵感而已，内容完全木有。羡慕很多大佬们，一周能产出五六篇文章，给我两个肝我都不够。好了，不多说废话了...

最近在线上环境遇到了一次SQL慢查询引发的数据库故障，影响线上业务。经过排查后，确定原因是SQL在执行时，MySQL优化器选择了错误的索引（不应该说是“错误”，而是选择了实际执行耗时更长的索引）。在排查过程中，查阅了许多资料，也学习了下MySQL优化器选择索引的基本准则，在本文中进行解决问题思路的分享。本人MySQL了解深度有限，如果错误欢迎理性讨论和指正。

在这次事故中也能充分看出深入了解MySQL运行原理的重要性，这是遇到问题时能否独立解决问题的关键。 试想一个月黑风高的夜晚，公司线上突然挂了，而你的同事们都不在线，就你一个人有条件解决问题，这时候如果被工程师的基本功把你卡住了，就问你尴不尴尬...

本文的主要内容：

• 故障描述
• 问题原因排查
• MySQL索引选择原理
• 解决方案
• 思考与总结

正文

故障描述

在7月24日11点线上某数据库突然收到大量告警，慢查询数超标，并且引发了连接数暴增，导致数据库响应缓慢，影响业务。看图表慢查询在高峰达到了每分钟14w次，在平时正常情况下慢查询数仅在两位数以下，如下图：

赶紧查看慢SQL记录，发现都是同一类语句导致的慢查询(隐私数据例如表名，我已经隐去)：

select
  *
from
  sample_table
where
    1 = 1
    and (city_id = 565)
    and (type = 13)
order by
  id desc
limit
  0, 1复制代码

看起来语句很简单，没什么特别的。但是每个执行的查询时间达到了惊人的44s。

简直耸人听闻，这已经不是“慢”能形容的了...

接下来查看表数据信息，如下图：

可以看到表数据量较大，预估行数在83683240，也就是8000w左右，千万数据量的表。

大致情况就是这样，下面进入排查问题的环节。

问题原因排查

首先当然要怀疑会不会该语句没走索引，查看建表DML中的索引：

KEY `idx_1` (`city_id`,`type`,`rank`),
KEY `idx_log_dt_city_id_rank` (`log_dt`,`city_id`,`rank`),
KEY `idx_city_id_type` (`city_id`,`type`)复制代码

请忽略idx_1和idx_city_id_type两个索引的重复，这都是历史遗留问题了。

可以看到是有idx_city_id_type和idx_1索引的，我们的查询条件是city_id和type，这两个索引都是能走到的。

但是，我们的查询条件真的只要考虑city_id和type吗？（机智的小伙伴应该注意到问题所在了，先往下讲，留给大家思考）

既然有索引，接下来就该看该语句实际有没有走到索引了，MySQL提供了Explain可以分析SQL语句。Explain 用来分析 SELECT 查询语句。

Explain比较重要的字段有：

• select_type : 查询类型，有简单查询、联合查询、子查询等
• key : 使用的索引
• rows : 预计需要扫描的行数

最后

以上就是英勇小海豚为你收集整理的因为MySQL选错索引导致的线上慢查询事故的全部内容，希望文章能够帮你解决因为MySQL选错索引导致的线上慢查询事故所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。