真正有效的慢日志优化是“配置→采集→分析→优化”四步闭环；需先确认slow_query_log=ON、long_query_time≤0.5、log_queries_not_using_indexes=ON生效，再用mysqldumpslow或pt-query-digest聚合分析，紧盯Query_time/Lock_time比值、Rows_examined与Rows_sent差值、执行频次及Extra字段，最后通过EXPLAIN和压测验证效果。
直接看原始慢日志文件效率低、信息杂乱，真正有效的做法是“配置→采集→分析→优化”四步闭环。重点不在日志本身，而在如何快速定位问题SQL并判断优化方向。
确认慢日志已开启并设好阈值
没开日志，后面全是空谈。先检查三项核心配置是否生效：
- slow_query_log = ON：必须启用，否则无日志可查
- long_query_time = 0.5（或更小）：默认10秒太宽松，建议设为0.5秒，能捕获更多潜在瓶颈
- log_queries_not_using_indexes = ON：即使执行快，但没走索引的语句也记下来，这类SQL常在数据量增长后突然变慢
配置可通过命令实时生效：
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
无需重启，但需确保 slow_query_log_file 路径存在且 MySQL 进程有写权限。
用工具解析，别手动翻日志
原始 slow.log 每行含时间、用户、IP、执行时长、扫描行数、SQL文本等，但相似SQL因参数不同被当成多条，难以归类。必须借助工具聚合分析：
-
mysqldumpslow（MySQL 自带）：适合快速筛查
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log → 按总耗时排序，取前10条
mysqldumpslow -g "order" slow.log → 筛出含 order 相关的慢查询 -
pt-query-digest（Percona Toolkit）：生产环境首选
输出含执行次数、平均响应、95% 延迟、全表扫描率、锁等待占比等，并附带索引建议
示例：pt-query-digest /var/log/mysql/mysql-slow.log --limit 10 > report.txt
盯紧四个关键指标
从工具输出中，不看SQL写法，先看这四点就能初步判断问题类型：
- Query_time 和 Lock_time 比值高：说明锁等待严重，可能是大事务、未提交操作或间隙锁冲突
- Rows_examined 远大于 Rows_sent（比如扫10万行只返10行）：大概率缺索引或索引失效，需结合 EXPLAIN 验证
- Count 高 + Query_time 中等：高频轻慢SQL，积少成多拖垮性能，优先加缓存或合并查询
- Extra 出现 Using filesort / Using temporary：排序或分组未走索引，考虑添加覆盖索引或改写 ORDER BY/GROUP BY 字段顺序
验证优化效果要靠 EXPLAIN + 实测
看到可疑SQL后，不能只改写就上线。务必做两件事：
- 在测试库执行 EXPLAIN FORMAT=TREE [SQL]，确认 type 是否为 const/ref，key 是否命中预期索引，rows 是否显著下降
- 用相同数据量、相似并发压测优化前后响应时间与 CPU/IO 消耗，避免“看起来快了，实际更耗资源”
