分析慢查询日志的核心是定位执行时间长、频率高或资源消耗大的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，通常需优化

基本上就这些。关键是持续监控、定期分析，并在测试环境验证优化效果，避免上线后引发新问题。