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

SQL慢查询排查核心是“先定位、再归因、后验证”：开启慢查询日志定位问题SQL，用EXPLAIN分析真实执行路径，聚焦索引失效、设计不合理及语句硬伤三类场景，最后通过测试库验证和线上监控闭环确认优化效果。

SQL慢查询排查不是靠猜，核心是“先定位、再归因、后验证”。关键不在改SQL或加索引本身，而在于建立一条可复现、可对比、可闭环的排查链路。

第一步：让慢SQL自己浮出水面

不开启慢查询日志，等于闭眼开车。必须打开它，并设合理阈值：

• MySQL中，在my.cnf里加：
  slow_query_log=1
long_query_time=0.5
log_queries_not_using_indexes=1
• 动态开启也行：
  SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 0.5;
• 重点看日志里的Query_time（真实耗时）、Rows_examined（扫描行数）、Rows_sent（返回行数）——三者比值异常，往往就是问题入口

第二步：用EXPLAIN还原真实执行路径

别拿开发环境的EXPLAIN当真，必须用线上慢日志里记录的完整SQL+真实参数去分析。否则容易误判，比如：

• type=ALL → 全表扫描，大概率缺索引或索引失效
• key=NULL → 明明建了索引却没用上
• rows远大于Rows_sent → 扫得多、回得少，可能有无效过滤或排序开销
• Extra里出现Using filesort或Using temporary → ORDER BY/GROUP BY没走索引，或字段类型不匹配

第三步：聚焦三类高频失效场景

80%的慢查根源集中在这几类，逐个对照检查：

标签： mysql ai 开发环境 隐式转换