MySQL慢查询日志需合理配置才能有效定位性能瓶颈：启用slow_query_log，设long_query_time（建议1.0秒），补充log_slow_admin_statements等提升分析价值，用mysqldumpslow或pt-query-digest聚合分析，再结合EXPLAIN验证优化效果。
MySQL 慢查询日志是定位性能瓶颈最直接有效的手段之一，但开启不等于生效，记录下来也不代表能快速发现问题。关键在于配置合理、日志可用、分析聚焦。
确认并启用慢查询日志功能
MySQL 默认通常关闭慢查询日志。需检查并设置以下参数：
- slow_query_log：设为 ON 才真正启用日志写入
- slow_query_log_file：指定日志文件路径（如 /var/log/mysql/mysql-slow.log），确保 MySQL 进程有写权限
- long_query_time：设定“慢”的阈值（单位秒），建议生产环境从 1.0 开始，高频小查询可调至 0.5；注意：MySQL 5.6+ 支持毫秒级（如 0.3）
- log_queries_not_using_indexes：可选开启，用于捕获未走索引的查询（但会显著增加日志量，建议临时开启排查）
修改后需执行 SET GLOBAL slow_query_log = ON; 或重启 MySQL 生效。用 SHOW VARIABLES LIKE 'slow_query_log'; 验证状态。
确保日志内容具备分析价值
仅记录 SQL 文本远远不够。推荐补充以下配置提升可读性与实用性：
- log_slow_admin_statements：设为 ON，让 ALTER TABLE、ANALYZE TABLE 等管理语句也进慢日志（这类操作常被忽略，却极易阻塞业务）
- log_slow_slave_statements（主从架构下）：在从库开启，便于识别复制延迟是否由慢查询引发
- min_examined_row_limit：例如设为 1000，过滤掉扫描行数极少但耗时略超阈值的“伪慢查询”，减少噪音
避免使用 log_output = TABLE（写入 mysql.slow_log 表），因频繁写入可能加重性能负担，文件方式更稳定可控。
用 mysqldumpslow 或 pt-query-digest 快速定位热点
原始慢日志文本冗长且重复多，人工翻阅效率极低。优先使用工具聚合分析：
-
mysqldumpslow（MySQL 自带）：轻量够用，例如：
mysqldumpslow -s at -t 10 /var/log/mysql/mysql-slow.log
表示按平均执行时间排序，输出前 10 条模板化语句 - pt-query-digest（Percona Toolkit）：更强大，支持分析、报告、对比、生成优化建议，还能解析 general log 或 tcpdump 抓包，适合深度诊断
重点关注输出中的 Count（出现频次）、Exec time（总耗时）、Rows examine/sent（扫描/返回行数比），三者结合才能判断是单次重查询，还是高频轻查询积压。
结合 EXPLAIN 与实际执行计划验证优化效果
找到可疑 SQL 后，不要急于加索引。先做两件事：
- 在对应环境（尤其是数据量接近线上的从库）执行 EXPLAIN FORMAT=JSON，看是否真走了预期索引、是否有 filesort / temporary、key_len 是否合理
- 用 SELECT ... INTO DUMPFILE 或 LIMIT 1 测试真实执行时间，排除客户端网络或缓存干扰
- 修改后，观察慢日志中该 SQL 模板是否消失，同时监控 Handler_read_* 和 Innodb_buffer_pool_reads 等指标是否同步改善
记住：一条慢查询的根因可能是统计信息过期、隐式类型转换、索引失效，也可能是应用层循环调用——日志只告诉你“哪里慢”，不告诉你“为什么慢”，必须结合上下文验证。
