SQL慢查询怎么排查_核心原理解析助你掌握关键方法【教学】

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) = 2025 → 改成create_time BETWEEN '2025-01-01' AND '2025-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验证”的习惯，而不是凭经验瞎调。