SQL慢查询排查需遵循“先定位、再分析、后验证”流程：第一步开启并解读慢日志，关注Query_time、Rows_examined等字段；第二步用真实参数还原SQL并EXPLAIN；第三步识别索引失效场景；第四步针对性优化索引与查询。
SQL慢查询排查不是靠猜，核心是“先定位、再分析、后验证”。重点不在一上来改SQL或加索引，而在于拿到真实执行场景下的证据——尤其是慢日志里的实际参数和执行耗时。
第一步：打开并读准慢查询日志
没日志，一切分析都是空中楼阁。必须先确认慢查询日志已开启，并设合理阈值：
- MySQL中在my.cnf里加两行：
slow_query_log=1和long_query_time=0.5（注意：0.5秒是实际可设最小粒度，MySQL会记录 >0.5s 的查询） - 同时建议开启
log_queries_not_using_indexes=1，捕获那些明明有索引却没走的“隐性慢SQL” - 日志里关键字段要盯紧：Query_time（真耗时）、Rows_examined（扫描行数）、Rows_sent（返回行数）——三者比值异常高，基本就是问题源头
第二步：用真实参数还原SQL，再explain
很多同学直接拿开发环境写的SQL去explain，结果线上跑得巨慢。原因很简单：参数不同，执行计划可能完全不同。
- 从慢日志里复制完整SQL，把
WHERE条件中的占位符替换成日志里记录的真实值（比如user_id=123456） - 在测试库或从库上执行
EXPLAIN FORMAT=JSON SELECT ...，重点关注：
— type是否为ALL（全表扫描）
— key是否为空（没走索引）
— rows是否远大于Rows_sent（大量无效扫描）
第三步：判断索引是否真正生效
有索引≠走索引。常见失效场景要一眼识别：
-
左模糊：
name LIKE '%abc'→ 索引失效；改成name LIKE 'abc%'才可能走 -
对字段做运算或函数：
WHERE YEAR(create_time) = 2024→ 改成create_time BETWEEN '2024-01-01' AND '2024-12-31' -
隐式类型转换：
WHERE mobile = 13812345678（mobile是varchar）→ 字符串字段别用数字比较 -
联合索引没按最左匹配：索引是
(a,b,c)，但查询只用了b = ?或c = ?→ 不会命中
第四步：针对性优化，不盲目加索引
加索引不是万能解药，要结合查询模式来设计：
- 高频等值+排序组合？比如
WHERE status=1 ORDER BY created_at DESC LIMIT 20→ 考虑联合索引(status, created_at) - 查询只返回几个字段，且经常一起出现？考虑覆盖索引，避免回表，例如
SELECT id, title, author FROM article WHERE type=2→ 索引建为(type, id, title, author) - 深分页
LIMIT 10000,20？改写为基于游标的查询：WHERE id > 123456 ORDER BY id LIMIT 20 - 大表单次查几百万行？先看业务是否真的需要——很多时候是前端没分页、导出逻辑写错，而非SQL问题
基本上就这些。排查链路清晰了，慢SQL就不再玄学。关键是养成“日志先行、参数还原、explain验证”的习惯，而不是凭经验瞎调。
