MySQL慢查询日志是定位性能瓶颈最直接可靠的入口，需先确认开启状态与路径，再用mysqldumpslow筛选、EXPLAIN分析真实参数SQL，最后用pt-query-digest等工具聚合分析。
MySQL慢查询日志是定位性能瓶颈最直接、最可靠的入口。不看日志就调优，等于蒙眼修车——可能修对，但大概率绕弯子。核心思路很明确：先让慢SQL“浮出水面”，再用真实执行上下文分析它为什么慢。
确认慢日志是否开启并知道它在哪
很多问题其实卡在第一步：日志根本没开，或者开了但不知道文件路径。别猜，直接查：
- 执行 SHOW VARIABLES LIKE 'slow_query_log' —— 返回 ON 才算开启；OFF 就得先打开
- 执行 SHOW VARIABLES LIKE 'slow_query_log_file' —— 这就是日志的绝对路径，比如 /var/lib/mysql/hostname-slow.log
- 执行 SHOW VARIABLES LIKE 'long_query_time' —— 看当前阈值（单位秒），默认是10，生产建议设为0.5～2之间
注意：SET GLOBAL 只对当前会话生效，重启后失效。要永久生效，必须改 /etc/my.cnf 或 /etc/mysql/my.cnf，加上：
slow_query_log = 1
long_query_time = 1
log_queries_not_using_indexes = 0（可选，避免索引缺失类噪音）
快速筛选出真正该关注的慢SQL
日志文件本身是纯文本，但直接 cat 或 tail -f 看效率低。优先用 MySQL 自带工具快速聚焦：
- mysqldumpslow -s t -t 10 /path/to/slow.log：按总耗时排序，取前10条——适合找“单次最伤”的SQL
- mysqldumpslow -s c -t 10 /path/to/slow.log：按出现频次排序，取前10条——适合找“高频小慢”的SQL，这类往往更影响整体TPS
- mysqldumpslow -g "JOIN" /path/to/slow.log：只看含 JOIN 的慢SQL，快速定位关联复杂度问题
输出里重点关注：Count（次数）、Time（平均/最大耗时）、Rows_examined（扫描行数）、Rows_sent（返回行数）。如果扫描10万行只返回10行，基本就是索引没走对或缺失。
用真实参数还原SQL再explain
日志里的SQL常带问号或抽象占位符（如 # Query_time: 1.234... SELECT * FROM user WHERE id = ?）。不能直接拿这个explain——参数不同，执行计划可能完全不同。
- 从日志中复制完整语句，把 ? 替换成实际值（比如从应用日志、binlog或监控平台补全）
- 在测试库或从库上执行 EXPLAIN FORMAT=TRADITIONAL SELECT ...
- 重点看：type（避免ALL）、key（是否命中索引）、rows（预估扫描行）、Extra（警惕Using temporary / Using filesort）
特别提醒：同一SQL，id=1 走主键，id IN (1,2,3,...1000) 可能全表扫。务必用真实参数测。
用专业工具做聚合分析（进阶）
当慢日志量大（每天GB级）、需要横向对比或生成报告时，命令行工具就力不从心了：
-
pt-query-digest（Percona Toolkit）：事实标准。一条命令输出统计摘要、TOP SQL、索引建议、甚至改写提示。例如：
pt-query-digest /var/log/mysql/slow.log --limit 10 - mysqlsla：轻量易装，支持自定义报表格式，适合中小团队快速上手
- DB-PULSE等可视化工具：支持Web界面查看趋势、TOP N、自动聚类相似SQL，适合日常巡检和告警联动
这些工具不是替代explain，而是帮你从“大海捞针”变成“精准定位目标鱼群”。
