慢查询日志的“高级用法”：从找慢SQL到做容量规划

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

慢查询日志，DBA最熟悉的工具，没有之一。

每次系统变慢，第一反应就是“去看看慢查询日志”。找到那条慢SQL，分析执行计划，加索引或改写法，问题解决。这是慢查询日志的标准用法——找慢SQL、修慢SQL。

但如果你只把慢查询日志当成“故障排查工具”，那你只用了它20%的价值。

剩下的80%是什么？建立性能基线、预测容量瓶颈、评估优化效果、发现潜在风险。今天把慢查询日志的“隐藏用法”一次讲透。

一、慢查询日志不只是“故障排查工具”，是“性能监控系统”

很多团队对慢查询日志的使用方式是：出问题了才去看。系统慢了，打开日志，找慢SQL，修完关掉，等下次出问题再重复。

这种用法的问题在于：你永远在“等问题发生了再处理”，而不是“提前看到趋势”。

正确的用法是：持续开启慢查询日志，定期分析，建立性能基线，用趋势数据指导优化决策。

慢查询日志记录的是“执行时间超过阈值的SQL”。如果把阈值设得合理（比如0.5秒或1秒），它本质上是一个持续运行的性能采样系统——它告诉你：哪些SQL在变慢、变慢的速度有多快、哪些表正在成为新的性能热点。

这些信息，单看某一天的日志是看不出来的，但拉长到一周、一个月、一个季度，趋势就会清晰地浮现出来。

二、隐藏用法一：建立性能基线，让“慢”有标准可依

没有基线的优化，就像没有尺子量长度——你不知道优化完到底是变快了还是变慢了，也不知道系统的正常状态是什么样的。

怎么做？

1. 设定一个合理的阈值：建议long_query_time=0.5或1秒。阈值太低日志太大，阈值太高漏掉问题。

2. 持续记录一周：收集一周的慢查询日志，用pt-query-digest或mysqldumpslow聚合分析。

3. 建立基线指标：记录以下数据的平均值和P95值：

   • 每日慢查询数量（总条数）

   • 每日慢查询总耗时

   • TOP 5慢查询的平均执行时间

   • 每日新增的慢查询SQL指纹

实际意义：

有了基线，你就可以回答这些问题：

• “这条SQL优化完到底快了多少？”——对比基线中的历史数据

• “系统整体性能在变好还是变差？”——看慢查询数量的周趋势

• “这个版本上线有没有引入性能问题？”——对比上线前后的慢查询数量

三、隐藏用法二：用慢查询趋势预测容量瓶颈

这是慢查询日志最有价值的“隐藏用法”——通过慢查询的增长趋势，提前预测容量瓶颈。

怎么做？

1. 按月统计慢查询数量：每个月慢查询的总条数、总耗时、平均耗时

2. 绘制趋势图：用Excel或Grafana把数据画成折线图

3. 识别拐点：如果连续3个月慢查询数量都在增长，且增速在加快，说明系统正在接近容量上限

4. 提前预警：在慢查询数量翻倍之前，提前规划扩容、分库分表或架构升级

真实案例：

某电商平台的慢查询监控数据如下：

从数据可以看出，慢查询数量的环比增速在逐月加快——这不是偶发的性能问题，而是系统整体容量在接近上限。业务量在增长，数据库的承载能力没有同步提升，导致越来越多的查询“掉出”了性能窗口。

如果等到6月业务高峰系统才崩，那就只能半夜扩容。而提前两个月看到趋势，就可以从容地规划读写分离、升级规格或调整架构。

四、隐藏用法三：验证优化效果，让优化有“回放”

很多团队做完优化就完了，没有人回去验证“优化到底有没有用”。有了持续记录的慢查询日志，验证优化效果就变得非常简单。

怎么做？

1. 优化前记录基线：记录优化前一周的慢查询数量和总耗时

2. 执行优化：加索引、改SQL、调参数

3. 优化后对比：对比优化后一周和优化前一周的数据

4. 量化收益：慢查询数量下降了多少？总耗时减少了多少？

实际意义：

• 向团队证明优化的价值：“慢查询数量从每天200条降到50条，下降了75%”

• 识别无效优化：如果优化后数据没有变化，说明优化方向错了，及时调整

• 为后续优化决策提供依据：哪种类型的优化收益最大？下次优先做哪种？

五、实践建议：从“查看”到“监控”

要把慢查询日志从“故障排查工具”升级为“容量规划工具”，只需要做三件事：

1. 持续开启，不要出问题才开

# my.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 0.5
log_queries_not_using_indexes = 1

不要担心日志文件太大——可以用logrotate做日志轮转，保留最近30天即可。如果日志量实在太大，可以配置动态采样率控制写入量。

2. 定期分析，不要等出问题才看

建议每周跑一次pt-query-digest，把分析结果存档。一个月下来，你就有了4份周报，趋势一目了然。对于生产环境，可以设置定时任务自动分析并生成报告。

3. 建立告警，不要让阈值变成摆设

如果慢查询数量突然比上周增加了50%以上，应该触发告警。说明系统可能出现了异常——可能是业务量突增、可能是某个SQL的执行计划变了、可能是硬件出了问题。在业务方投诉之前，你先发现了。

六、一个完整的监控闭环

把慢查询日志纳入日常监控体系后，完整的闭环应该是这样的：

1. 数据采集：持续开启慢查询日志，记录所有超过阈值的SQL

2. 定期分析：每周用pt-query-digest聚合分析，生成周报

3. 趋势判断：对比本周与上周、上月的慢查询数据，判断趋势

4. 容量预警：慢查询数量连续增长超过20%时触发预警

5. 优化执行：定位TOP慢查询，执行优化

6. 效果验证：优化后对比数据，确认收益

这个闭环的核心理念是：用数据驱动决策，而不是等故障来了再处理。

七、总结

慢查询日志的价值，远不止“找慢SQL”这么简单：

• 建立性能基线：让“快”和“慢”有标准可依

• 预测容量瓶颈：通过慢查询的增长趋势提前规划扩容

• 验证优化效果：用数据证明优化的价值

把慢查询日志从“偶尔查看”变成“持续监控”，你就能从“查问题”走向“看趋势”。系统还没崩你就知道它快崩了——这才是DBA进阶的核心能力。

小耶在手，SQL 不愁

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~