关注
鸿蒙技术社区
，回复
【鸿蒙】
送价值
399元
的鸿蒙
开发板套件
（数量有限，先到先得），还可以
免费下载
鸿蒙
入门资料
！
👇
扫码
立刻关注
👇
专注开源技术，共建鸿蒙生态
最近在线上环境遇到了一次 SQL 慢查询引发的数据库故障，影响线上业务。
经过排查后，确定原因是：SQL 在执行时，MySQL 优化器选择了错误的索引（不应该说是“错误”，而是选择了实际执行耗时更长的索引）。
排查过程中，查阅了许多资料，也学习了下 MySQL 优化器选择索引的基本准则，在本文中进行解决问题思路的分享。
PS：本人 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 * from sample_table where city_id = 565 and type = 13 order by id desc limit 0,1
得到结果：
可以看出，虽然 possiblekey 有我们的索引，但是最后走了主键索引。而表是千万级别，并且该查询条件最后实际是返回的空数据，也就是 MySQL 在主键索引上实际检索时间很长，导致了慢查询。
我们可以使用 force index(idx_city_id_type) 让该语句选择我们设置的联合索引：
select * from sample_table force index(idx_city_id_type) where ( ( (1 = 1) and (city_id = 565) ) and (type = 13) ) order by id desc limit 0, 1
这次明显执行得飞快，分析语句：
实际执行时间 0.00175714s，走了联合索引后，不再是慢查询了。
问题找到了，总结下来就是：
MySQL 优化器认为在 limit 1 的情况下，走主键索引能够更快的找到那一条数据，并且如果走联合索引需要扫描索引后进行排序，而主键索引天生有序，所以优化器综合考虑，走了主键索引。
实际上，MySQL 遍历了 8000w 条数据也没找到那个天选之人（符合条件的数据），所以浪费了很多时间。
MySQL 一条语句的执行流程大致如下图，而查询优化器则是选择索引的地方：
引用参考文献一段解释：首先要知道，选择索引是 MySQL 优化器的工作。
而优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。
在数据库里面，扫描行数是影响执行代价的因素之一。扫描的行数越少，意味着访问磁盘数据的次数越少，消耗的 CPU 资源越少。
