SQL慢查询怎么排查_深入讲解快速提升实战能力【技巧】

慢查询排查需按日志定位、真实参数还原、执行计划分析、索引验证四步闭环进行，关键在于使用带真实参数的SQL执行EXPLAIN并结合慢日志中的Query_time和Rows_examined综合判断。

排查 SQL 慢查询不是靠猜，而是靠证据链：从日志定位、参数还原、执行计划分析，到索引验证，环环相扣。关键不在于“会不会 explain”，而在于“有没有用对顺序”和“有没有带真实参数”。

一、先让慢 SQL 自己“开口说话”——开启并读懂慢查询日志

这是所有排查的起点，跳过这步直接 explain，就像没查病灶就开药方。

• 动态开启（立即生效，适合临时诊断）：
  SET GLOBAL slow_query_log = 1;
  SET GLOBAL long_query_time = 0.5;
  注意：long_query_time 实际按秒向下取整，0.5 表示记录 >0.5 秒的语句（含 0.5001 秒）。
• 配置文件永久开启（推荐生产环境）：
  在 my.cnf 的 [mysqld] 下添加：
  slow_query_log = 1
  slow_query_log_file = /var/log/mysql/slow.log
  long_query_time = 1
  log_queries_not_using_indexes = 1
  后者能抓出“明明有索引却没走”的隐形问题。
• 看日志时盯紧三行：
  Query_time（真实耗时）、Rows_examined（扫描行数）、SQL 本身（注意末尾可能带参数值，比如 WHERE user_id=12345）。

二、别拿测试数据“演戏”——用真实参数还原 SQL 再 explain

同一句 SQL，参数不同，MySQL 可能走完全不同的执行路径。用 WHERE id = ? 这种占位符 explain，结果毫无参考价值。

• 从慢日志里复制完整 SQL，把实际参数填进去，例如：
  日志中是 SELECT * FROM orders WHERE status=1 AND create_time > '2025-11-01'，就拿这整条去 explain。
• 执行 EXPLAIN FORMAT=TRADITIONAL SELECT ...，重点关注：
  type：ALL（全表扫描）或 index（全索引扫描）要立刻警惕；
  rows：预估扫描行数，超 1 万建议优化；
  key：实际使用的索引名，为空说明没走索引；
  Extra：出现 Using filesort 或 Using temporary 是排序/分组性能瓶颈信号。

三、索引不是越多越好，而是“刚好够用”——聚焦命中与结构

加索引前先问三个问题：这个字段是否高频出现在 WHERE / JOIN / ORDER BY 中？当前 SQL 是否真能用上它？它的数据分布是否足够区分？

标签： mysql redis ssl ai 配置文件 性能瓶颈 隐式类型转换 red 2025