大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
慢查询日志，DBA最熟悉的工具，没有之一。
每次系统变慢，第一反应就是“去看看慢查询日志”。找到那条慢SQL，分析执行计划，加索引或改写法，问题解决。这是慢查询日志的标准用法——找慢SQL、修慢SQL。
但如果你只把慢查询日志当成“故障排查工具”，那你只用了它20%的价值。
剩下的80%是什么？建立性能基线、预测容量瓶颈、评估优化效果、发现潜在风险。今天把慢查询日志的“隐藏用法”一次讲透。
一、慢查询日志不只是“故障排查工具”，是“性能监控系统”
很多团队对慢查询日志的使用方式是：出问题了才去看。系统慢了，打开日志，找慢SQL，修完关掉，等下次出问题再重复。
这种用法的问题在于：你永远在“等问题发生了再处理”，而不是“提前看到趋势”。
正确的用法是：持续开启慢查询日志，定期分析，建立性能基线，用趋势数据指导优化决策。
慢查询日志记录的是“执行时间超过阈值的SQL”。如果把阈值设得合理（比如0.5秒或1秒），它本质上是一个持续运行的性能采样系统——它告诉你：哪些SQL在变慢、变慢的速度有多快、哪些表正在成为新的性能热点。
这些信息，单看某一天的日志是看不出来的，但拉长到一周、一个月、一个季度，趋势就会清晰地浮现出来。
二、隐藏用法一：建立性能基线，让“慢”有标准可依
没有基线的优化，就像没有尺子量长度——你不知道优化完到底是变快了还是变慢了，也不知道系统的正常状态是什么样的。
怎么做？
- 设定一个合理的阈值：建议
long_query_time=0.5或1秒。阈值太低日志太大，阈值太高漏掉问题。 - 持续记录一周：收集一周的慢查询日志，用
pt-query-digest或mysqldumpslow聚合分析。 - 建立基线指标：记录以下数据的平均值和P95值：
- 每日慢查询数量（总条数）
- 每日慢查询总耗时
- TOP 5慢查询的平均执行时间
- 每日新增的慢查询SQL指纹
实际意义：
有了基线，你就可以回答这些问题：
- “这条SQL优化完到底快了多少？”——对比基线中的历史数据
- “系统整体性能在变好还是变差？”——看慢查询数量的周趋势
- “这个版本上线有没有引入性能问题？”——对比上线前后的慢查询数量
三、隐藏用法二：用慢查询趋势预测容量瓶颈
这是慢查询日志最有价值的“隐藏用法”——通过慢查询的增长趋势，提前预测容量瓶颈。
怎么做？
- 按月统计慢查询数量：每个月慢查询的总条数、总耗时、平均耗时
- 绘制趋势图：用Excel或Grafana把数据画成折线图
- 识别拐点：如果连续3个月慢查询数量都在增长，且增速在加快，说明系统正在接近容量上限
- 提前预警：在慢查询数量翻倍之前，提前规划扩容、分库分表或架构升级
真实案例：
某电商平台的慢查询监控数据如下：
| 月份 | 慢查询总数 | 环比增长 |
| 1月 | 12,000 | — |
| 2月 | 13,800 | +15% |
| 3月 | 16,500 | +20% |
| 4月 | 21,000 | +27% |
| 5月 | 28,000 | +33% |
从数据可以看出，慢查询数量的环比增速在逐月加快——这不是偶发的性能问题，而是系统整体容量在接近上限。业务量在增长，数据库的承载能力没有同步提升，导致越来越多的查询“掉出”了性能窗口。
如果等到6月业务高峰系统才崩，那就只能半夜扩容。而提前两个月看到趋势，就可以从容地规划读写分离、升级规格或调整架构。
四、隐藏用法三：验证优化效果，让优化有“回放”
很多团队做完优化就完了，没有人回去验证“优化到底有没有用”。有了持续记录的慢查询日志，验证优化效果就变得非常简单。
怎么做？
- 优化前记录基线：记录优化前一周的慢查询数量和总耗时
- 执行优化：加索引、改SQL、调参数
- 优化后对比：对比优化后一周和优化前一周的数据
- 量化收益：慢查询数量下降了多少？总耗时减少了多少？
实际意义：
- 向团队证明优化的价值：“慢查询数量从每天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的执行计划变了、可能是硬件出了问题。在业务方投诉之前，你先发现了。
六、一个完整的监控闭环
把慢查询日志纳入日常监控体系后，完整的闭环应该是这样的：
- 数据采集：持续开启慢查询日志，记录所有超过阈值的SQL
- 定期分析：每周用
pt-query-digest聚合分析，生成周报 - 趋势判断：对比本周与上周、上月的慢查询数据，判断趋势
- 容量预警：慢查询数量连续增长超过20%时触发预警
- 优化执行：定位TOP慢查询，执行优化
- 效果验证：优化后对比数据，确认收益
这个闭环的核心理念是：用数据驱动决策，而不是等故障来了再处理。
七、总结
慢查询日志的价值，远不止“找慢SQL”这么简单：
- 建立性能基线：让“快”和“慢”有标准可依
- 预测容量瓶颈：通过慢查询的增长趋势提前规划扩容
- 验证优化效果：用数据证明优化的价值
把慢查询日志从“偶尔查看”变成“持续监控”，你就能从“查问题”走向“看趋势”。系统还没崩你就知道它快崩了——这才是DBA进阶的核心能力。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
