排查MySQL慢查询需按四步顺序执行：先开启并确认慢查询日志生效；再用pt-query-digest等工具定位高频高耗时SQL；接着还原真实参数用EXPLAIN分析执行计划；最后针对性优化并验证效果。
排查 MySQL 慢查询不能靠猜，得按顺序抓关键证据：先让慢 SQL 现形，再看它到底干了什么，最后动手优化。整个过程环环相扣，跳步容易白忙活。
一、开启并确认慢查询日志生效
这是所有排查的起点。没日志，等于没监控探头。
- 先检查状态：
SHOW VARIABLES LIKE 'slow_query_log';返回ON才算开启 - 临时开启（重启失效）：
SET GLOBAL slow_query_log = ON;+SET GLOBAL long_query_time = 1; - 永久生效要改配置文件
/etc/my.cnf或/etc/mysql/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 = ON - 注意：
long_query_time单位是秒，写0.5表示记录超 500ms 的查询；修改后需重启 MySQL 或用SET PERSIST（MySQL 8.0+）才持久
二、快速定位“高频”和“高耗时”慢 SQL
日志文件本身是文本，直接翻看效率低。优先用工具聚合分析。
- 用 MySQL 自带工具：
mysqldumpslow -t 10 -s at /var/log/mysql/slow.log—— 查耗时 Top 10 - 更推荐 Percona Toolkit：
pt-query-digest /var/log/mysql/slow.log，能自动归类相似 SQL、统计执行次数、平均耗时、扫描行数等 - 重点盯三类 SQL：执行频次高、
Rows_examined远大于Rows_sent、带Using filesort或Using temporary的
三、还原真实参数，用 EXPLAIN 看执行计划
别拿测试数据或空 WHERE 条件去 explain。线上慢的，往往是特定参数触发了错误索引路径。
- 从慢日志里复制完整 SQL（含注释里的
SET timestamp=...和实际参数） - 在测试库或从库上执行：
EXPLAIN FORMAT=TREE SELECT ...（MySQL 8.0+ 推荐 TREE 格式，逻辑更清晰） - 核心看四点：
–type：避免ALL（全表扫描）、index（全索引扫描）
–key：是否命中预期索引？NULL表示没走索引
–rows：预估扫描行数，和慢日志里的Rows_examined对比是否接近
–Extra：警惕Using filesort、Using temporary、Using join buffer
四、针对性优化与验证
优化不是加索引就完事，得匹配查询模式和数据分布。
- 如果
WHERE条件字段没索引，优先建单列或联合索引（注意最左前缀） - 如果
ORDER BY字段没被索引覆盖，考虑扩展索引包含排序字段，或改写为覆盖索引查询 - 如果
JOIN表过大，检查驱动表选择是否合理，必要时用STRAIGHT_JOIN强制顺序 - 优化后，必须回到原环境用相同参数再
EXPLAIN，确认执行计划已变；再压测验证响应时间和Rows_examined是否下降
