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（大量无效扫描）

第三步：判断索引是否真正生效

有索引≠走索引。常见失效场景要一眼识别：

标签： mysql js 前端 json ai 开发环境 隐式类型转换