前言

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

最近在线上环境遇到了一次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)
orderby
iddesc
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 : 预计需要扫描的行数

更多详细Explain介绍可以