分析慢查询日志的核心是定位执行时间长、频率高或资源消耗大的SQL语句，通过开启慢查询日志并设置合理阈值（如long_query_time=0.5）、记录未使用索引的查询，利用mysqldumpslow或pt-query-digest工具解析日志，重点关注执行时间、扫描行数与返回行数比值、执行频率及锁等待时间，结合EXPLAIN分析执行计划，检查是否全表扫描、索引使用情况及Extra列中的Using filesort或Using temporary等问题，根据业务场景优化SQL并在测试环境验证效果，持续监控以提升数据库性能。
分析慢查询日志的核心是找出执行时间长、频率高或资源消耗大的SQL语句，进而优化数据库性能。关键在于定位问题SQL、理解其执行计划，并结合业务场景进行调优。
开启并配置慢查询日志
确保数据库已启用慢查询日志，并设置合理的阈值：
- MySQL：检查slow_query_log = ON，设置long_query_time（如0.5秒）
- 记录未使用索引的查询：log_queries_not_using_indexes = ON
- 日志文件路径由slow_query_log_file指定，确认有读取权限
使用工具解析日志内容
原始日志可读性差，推荐用工具提取关键信息：
-
mysqldumpslow：MySQL自带，汇总统计最慢或最频繁的SQL
示例：mysqldumpslow -s c -t 10 slow.log（按出现次数排序，取前10条） -
pt-query-digest（Percona Toolkit）：功能强大，输出执行统计、执行计划、建议等
命令示例：pt-query-digest slow.log > analysis.txt
重点分析SQL的执行特征
从日志或工具输出中关注以下指标：
- 执行时间：是否明显超过预期？是否存在突增？
- 扫描行数 vs 返回行数：若扫描大量数据仅返回少量记录，可能缺少有效索引
- 执行频率：偶尔慢的SQL影响小，高频慢查询优先处理
- 锁等待时间：长时间等待锁可能是并发竞争或事务过大
结合EXPLAIN分析执行计划
对可疑SQL使用EXPLAIN查看实际执行路径：
- 检查是否全表扫描（type=ALL），应尽量避免
- 确认是否使用了正确的索引（key字段）
- 观察rows预估是否与实际扫描量接近
- 注意Extra列中的Using filesort或Using temporary，通常需优化
基本上就这些。关键是持续监控、定期分析，并在测试环境验证优化效果，避免上线后引发新问题。
