SQL慢查询怎么排查_完整逻辑拆解助力系统化掌握【指导】

sql慢查询排查按三步进行：先通过慢查询日志定位真实慢SQL，再用EXPLaiN分析执行计划，最后验证索引与结构是否合理；每步需严格闭环验证。

SQL慢查询排查不是靠猜，而是按顺序抓关键证据：先确认它真慢、再看它怎么慢、最后判断为什么慢。核心逻辑就三步——日志定位 → 执行计划分析 → 索引与结构验证。

第一步：让数据库自己“报错”——开启并读取慢查询日志

不看日志就调优，等于蒙眼修车。必须先让 mysql 把慢的 SQL 记下来：

• 临时开启（测试环境快）：
  SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 0.5;（注意：0.5 是最小有效值，MySQL 不支持 0.1 秒级精度）
• 永久生效（生产环境必做）：在 my.cnf 加三行：
  slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5
• 别漏掉这个开关：log_queries_not_using_indexes = 1，能帮你揪出“明明有索引却没用”的隐形问题
• 日志里重点盯三项：Query_time（真实耗时）、Rows_examined（扫描行数）、SQL 模板本身（注意参数是否被泛化）

第二步：还原真实现场——用 EXPLAIN 看执行计划

不能拿开发环境里带 LIMIT 的简化版 SQL 去 explain，必须用慢日志里记录的**完整语句 + 实际参数**还原执行场景：

• 执行 EXPLAIN format=jsON select ...（json 格式信息更全，尤其看 actual_rows 和预估偏差）
• 重点关注这几列：
  • type：出现 ALL（全表扫描）或 index（全索引扫描）基本就是瓶颈；
  • key 和 possible_keys：实际用了哪个索引？有没有更优索引没被选中？
  • rows：MySQL 预估要扫多少行？如果远大于结果集，说明索引效率低或统计信息不准；
  • Extra：出现 Using filesort 或 Using temporary 表示排序/分组被迫走磁盘，得加覆盖索引

第三步：查索引和数据结构——验证“为什么没走索引”

很多慢查询不是没建索引，而是索引被悄悄绕过了。常见失效原因直接对应字段设计和写法：

易标AI

告别低效手工，迎接AI标书新时代！3分钟智能生成，行业唯一具备查重功能，自动避雷废标项

135

查看详情

• 隐式类型转换：比如 WHERE mobile = 13812345678（mobile 是 varchar），MySQL 会放弃索引转成全表扫描
• 函数操作字段：如 WHERE date(create_time) = '2025-12-01'，索引无法下推，应改写为 create_time >= '2025-12-01' AND create_time
• 前导通配符：LIKE ‘%abc’ 无法使用 B+Tree 索引，考虑全文索引或倒排表
• 联合索引顺序错位：索引是 (a,b,c)，但查询只用 WHERE b = ?，那 a 没出现在条件里，索引就失效
• 检查外键字段：像 order.user_id 关联 user.id，如果 user_id 没单独建索引，JOIN 就可能变嵌套循环+全表扫描

第四步：验证与闭环——改完必须回归验证

加了索引或改了 SQL，不代表就快了。必须闭环验证：

• 在测试库用相同数据量、相同并发压测，对比 EXPLAIN 中的 rows 和 key 是否变化
• 观察慢日志里该 SQL 是否不再出现，或 Query_time 显著下降（比如从 2s → 80ms）
• 注意缓存干扰：首次执行可能慢（磁盘IO），连续执行几次取稳定值；必要时用 SELECT SLEEP(0) 清空 Query Cache（MySQL 5.7+ 已默认禁用）
• 别忽略业务语义：有时候“优化”后 SQL 快了，但返回了错误数据（比如忘了加 WHERE 条件），务必核对结果集正确性

基本上就这些。不复杂，但容易忽略真实参数、索引失效细节和验证闭环。慢查询排查，本质是把黑盒执行过程一步步显性化。