慢查询日志分析需三步：一设合理阈值并开启log_queries_not_using_indexes确保日志代表性；二用pt-query-digest按时间范围筛选高危sql；三借explain验证索引实效性，关注type、rows、extra字段，结合analyze table与监控告警形成闭环。

直接分析慢查询日志本身不能解决问题，关键在于把日志变成可执行的优化动作。核心是三步走：先让日志有代表性，再用工具筛出真问题，最后靠执行计划验证改得对不对。

让慢查询日志真正反映业务瓶颈

日志没用，往往是因为它根本没记对东西：

• 阈值别硬套“1秒”——高并发交易系统可能设为0.2秒，后台报表类可放宽到3秒，关键是和业务响应预期匹配
• 必须打开log_queries_not_using_indexes，很多慢查询不超时却拖垮性能，就因为走了全表扫描但没被long_query_time捕获
• 日志路径要独立挂载，避免和数据目录共用磁盘导致IO争抢；定期用logrotate做轮转，防止单个日志文件过大影响分析效率

用pt-query-digest快速锁定高危SQL

mysqldumpslow只能看个大概，真正要排优先级得靠pt-query-digest：

HTML5主机托管服务公司网站模板

HTML5主机托管服务公司网站模板是一款从事主机托管服务公司宣传网站模板下载。提示：本模板调用到谷歌字体库，可能会出现页面打开比较缓慢。

下载

• 运行pt-query-digest /var/log/mysql/slow.log --since "2026-08-10 00:00:00"，限定时间范围，避开发布变更等干扰时段
• 重点关注报告顶部的“Profile”部分：看Query_time sum（总耗时）和Count（执行次数）双高的语句，这类SQL对整体延迟影响最大
• 报告里带“# Query 1”标记的示例SQL，复制出来直接在库上跑EXPLAIN，别只看摘要

用EXPLAIN验证索引是否真正生效

看到“已加索引”不等于问题解决，得看MySQL实际怎么用它：

• type字段出现ALL或index，说明还是扫了整张表或整个索引树，得检查WHERE条件是否符合最左前缀原则
• rows值远大于实际返回行数（比如查10条却预估扫描50万行），大概率是统计信息过期，执行ANALYZE TABLE 表名更新
• Extra里出现Using filesort，不是加个ORDER BY字段索引就能解决——要确保排序字段在索引中位置靠后且没被范围查询截断

把分析结果变成可持续动作

一次优化管不了半年，得让流程跑起来：

• 每天凌晨用crontab自动跑pt-query-digest，把前1小时日志生成简报邮件，标题标出TOP3慢SQL的耗时变化
• 开发提测时强制附上核心接口的EXPLAIN结果截图，DBA只审核key、rows、Extra三项
• 在监控大盘里加一条“慢查询QPS”，趋势突增时自动触发告警，而不是等用户投诉才翻日志