分析慢查询日志的核心是找出执行时间长、频率高或资源消耗大的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，通常需优化基本上就这些。关键是持续监控、定期分析，并在测试环境验证优化效果，避免上线后引发新问题。
