慢查询分析实战：从日志参数配置到数据库监控告警体系

凌晨两点四十七分，告警群弹出一条消息：订单查询接口的P99延迟从180毫秒飙到3.8秒。第一反应当然是去看数据库监控，但CPU、内存、磁盘IO全是绿的，什么问题都看不出来。直到有人打开了那台实例的慢查询日志，才发现在过去两个多小时里，某条关联三张大表的SQL一直在后台“磨洋工”，每次执行扫了200多万行，业务高峰期一到，连接池直接被拖死。

这种场景我遇到过太多次。数据库监控如果只盯资源指标，就永远只能看到“果”，看不到“因”。而慢查询分析，恰恰是定位这个“因”最直接的入口。这篇文章想聊的，就是怎么把数据库监控和慢查询分析真正结合起来：从慢查询日志的参数配置、采集方式，到拿到一堆慢SQL之后如何系统性地定位病根，再到如何把慢查询变成一套可告警、可观测的监控体系。内容主要面向需要自己维护数据库的后端开发、DBA和SRE，尤其是那些还停留在“看CPU高不高、连接数多不多”阶段的团队，这篇文章应该能帮你把监控思路理顺。

1. 慢查询为什么值得单独架一套监控

1.1 一条SQL的失控并不是“慢慢变慢”

很多人对慢查询有个误解，觉得一条SQL变慢是渐进的，今天500ms，明天600ms，后天700ms。真去生产环境看，你会发现它往往是断崖式的。

原因很简单：执行计划是优化器基于统计信息选出来的，而统计信息不会每时每刻都在更新。当表数据量涨过某个临界点，或者某个索引的区分度发生了变化，优化器可能突然抛弃原本合适的索引，换成一个灾难性的执行计划。比如原来走索引只扫几千行，一夜之间变成全表扫描，扫描行数从几千跳到几百万。这种变化不是线性变慢，而是直接从100ms跳到3000ms。

更麻烦的是连锁反应。一条SQL变慢后，它持有的数据库连接不会被立刻释放，后续新请求会不断堆积，连接池被打满。再往后，其他本来很快的查询也因为拿不到连接而集体超时。这时候去看数据库监控，你会看到活跃会话数飙升、连接数打满、CPU和IO可能都被拉高。但这些都是表象，底层原因是那一条慢SQL。如果监控体系不带慢查询维度，排查方向很容易被资源告警带偏，折腾半天才发现罪魁祸首是谁。

1.2 常规数据库监控最容易漏掉的一层

大多数团队搭建的数据库监控，逃不出这几项：实例是否存活、CPU使用率、内存使用率、磁盘空间、连接数、QPS/TPS。这套东西管不管用？当然管用，但它管的是“数据库这台机器/进程是否健康”，不管“数据库里跑的SQL是否健康”。

一台数据库CPU使用率100%，一定是有问题的。但问题可能是某条烂SQL，也可能是某个大事务，也可能是备份任务撞上业务高峰。只看资源监控，你只能知道“出事了”，不知道“哪里出事了”。慢查询监控补的正是这一层：它直接告诉你哪些SQL超出了预期耗时、扫描了多少行、在什么时间点执行。把慢查询分析结果和CPU、连接数这些资源指标放在一起看，才能从“实例出问题”一路追踪到“具体是哪条SQL捅的娄子”。

我记得有一次帮一个团队排查线上问题，他们的MySQL实例每天凌晨CPU都会周期性飙高，检查了定时任务、备份策略、系统负载，都没找到原因。后来翻了慢查询日志，发现是一条统计报表SQL每天凌晨四点准时执行，这个时间点正好和数据仓库的抽取任务重叠，两边抢IO资源。这种问题，如果只有系统层监控，几乎不可能定位。

1.3 不能只记日志，要把它变成指标

仅仅开启慢查询日志、出问题时翻一翻，这不算监控，只能叫事后审计。真正的慢查询监控，至少要把这几个东西变成可观测的指标：单位时间内的慢查询数量、慢查询总耗时、参与排名的SQL模板、某条高频慢查询的执行次数变化趋势。

为什么要强调“模板”而不是“单条SQL”？因为线上SQL五花八门，每次查询的条件值都不一样。一条加了用户ID等值条件的SQL，今天慢明天不慢，单独看每一条很难发现规律。但把查询结构相同、只是条件值不同的SQL归类成一个模板后，就能算出这个模板的平均耗时、最大耗时、执行频率。一旦某个模板的响应时间开始逐小时爬升，哪怕还没触发慢查询阈值，你也知道它快出问题了。这才是慢查询分析对监控体系最大的价值——它让数据库监控的粒度从“实例级”细化到了“SQL模板级”。

2. 把慢查询日志吃透：参数组合与采集方案

2.1 MySQL侧的最小配置并不止一个开关

很多人以为开启慢查询日志就是把 slow_query_log 设为 ON，其他完事。如果你的 MySQL 还是默认配置，那抓出来的慢日志会漏掉大量关键信息。

我自己常用的参数组合大概是这样的：

long_query_time 设成多少，其实是门学问。设成1秒，日志量可控，但会漏掉那些单个查询只要300ms、但每秒被执行几百次的问题SQL——单看不慢，积少成多，对数据库压力极大。设成0.1秒，日志又会多到让人不想看。我的建议是业务初期设1秒先跑着，等日志分析流程跑顺了，再针对核心业务库下调到0.2秒或0.5秒。

log_queries_not_using_indexes 这个开关要特别注意。它的初衷是好的：即使查询只要50ms，但只要没走索引就记下来，帮你在数据量涨起来之前发现隐患。但如果不加 log_throttle_queries_not_using_indexes 限流，一次全表扫描的报表查询就能让日志文件瞬间多出几万条记录，磁盘直接写满。我见过有人把这个开关打开后第二天早上发现慢日志文件膨胀到几十个GB，整台实例磁盘告警。所以这两个参数必须搭配着开。

2.2 日志里每一列都值得细看

很多初学者拿到慢查询日志，只盯着 Query_time 看，看到一条SQL耗时5秒，就开始琢磨怎么优化。这没错，但往往会漏掉日志里其他更有价值的线索。

一条典型的MySQL慢日志长这样：

text复制# Time: 2025-04-12T02:47:33.218477Z
# User@Host: app_user[app_user] @  [10.20.1.35]
# Query_time: 3.211752  Lock_time: 0.000392 Rows_sent: 10  Rows_examined: 2180534
SET timestamp=1742630853;
SELECT id, order_no, user_id, amount, status
FROM orders
WHERE status = 2
  AND create_time BETWEEN '2025-03-01 00:00:00' AND '2025-03-31 23:59:59'
ORDER BY id DESC
LIMIT 10;

Query_time 是总执行时间，Lock_time 是锁等待时间。如果 Lock_time 占总时间的比例很高，比如超过50%，那这条SQL大概率不是SQL本身写得差，而是在等锁。Rows_sent 只有10行，Rows_examined 却扫了218万行，这两者的比值是判断SQL是否健康的核心指标。扫描行数比返回行数高出几个数量级，说明查询走了错误路径，或者索引设计得不对。这条日志里2,180,534:10的比例，明显就是没有有效索引的情况。

还有个细节要提醒：日志里的 Time 是SQL执行结束写入日志的时间，不是SQL开始执行的时间。在分析“某条慢SQL是否撞上了业务高峰期”时，不能只靠日志时间下结论，最好结合监控系统里的会话开始时间一起看。

2.3 采集方案：别让慢日志躺在服务器里睡觉

日志采集有以下几种常见方案：

裸奔方案：每天手动登录服务器，用 mysql 命令导出慢日志，再本地打开分析。适合只有一两台实例、慢查询一天也没几条的场景。但只要你管理的实例超过三台，这个方案就不现实，你会漏掉大量问题。

方案一：ELK/日志平台采集：用Filebeat或Logstash采集慢日志文件，解析成结构化字段后写入Elasticsearch，再在Kibana里做检索和可视化。好处是检索方便，能按时间范围、耗时、扫描行数自由筛选。坏处是慢日志本身是文本，需要自己写正则做字段解析，而且ELK这套体系通常归中间件团队管，每次要看慢日志还得切到另一个平台。

方案二：pt-query-digest定期分析：Percona Toolkit里的 pt-query-digest 是分析MySQL慢日志的经典工具。它可以对慢日志做聚合、归类和排名，把成千上万条SQL聚合成几十个模板，输出每类SQL的调用次数、平均耗时、耗时占比。配合 crontab 每天凌晨跑一次，把结果输出成HTML或文本报告。但它的分析基于历史日志文件，无法做到实时告警。

方案三：基于performance_schema的实时采集：这也是我目前比较推荐的方式。MySQL的 performance_schema 库里维护了大量SQL执行统计，比如 events_statements_summary_by_digest 表，按SQL模板聚合了执行次数、总耗时、平均耗时、扫描行数等指标。监控系统（比如Prometheus的mysqld_exporter）可以从这张表定期拉取数据，不需要解析日志文件，就能实时看到哪些SQL模板最耗资源。这部分在后面讲监控体系时再展开。

如果你把MySQL跑在容器里，有一个坑要特别注意：慢日志如果写到容器本地文件，容器重建后文件就没了，排障时找不到历史日志非常被动。要么把慢日志目录挂载到宿主机持久化存储，要么把监控重点放在performance_schema这种不依赖日志文件的数据源上，两条路至少要选一条。

3. 从一堆慢SQL到病根：分析的标准动作与关键信号

3.1 先聚合归类，再逐条下钻

我见过不少人拿到慢日志之后，直接打开文件从第一条开始看。如果一天只有几十条慢SQL，这个方法还行；如果一天有几万条，这么看只会让人崩溃，而且看不出规律。

正确姿势是先做聚合。比如 pt-query-digest 可以直接把慢日志里结构相同的SQL归并成一个模板：

bash复制pt-query-digest /var/log/mysql/mysql-slow.log --limit=20 > slow_report.txt

输出结果里最值得关注的是它生成的Profile表格，大概长这样：

text复制Rank Query ID           Response time  Calls R/Call V/M   Item
1   0xABCD1234EF567890  5321.2312 63.2% 1243  4.2815 0.45 SELECT orders
2   0x1234567890ABCDEF  1542.8812 18.3% 452   3.4136 1.23 SELECT users
3   0x5678901234ABCDEF  432.1203   5.1%   78   5.5400 0.02 SELECT products

这个表已经足够告诉你：第一优先级是SELECT orders那批SQL，1243次调用贡献了63%的慢查询总耗时。接下来才是下一步动作。

还有一个关键指标是V/M，也就是响应时间的变异系数，反映同一模板下不同次执行时间的波动程度。V/M 很高，说明这条SQL的执行时间忽快忽慢，那就要警惕执行计划不稳定，可能一会儿走索引一会儿没走索引。V/M 较低但平均耗时很高，说明每次执行都很稳定地慢，大概率是本身的索引设计或查询写法出了问题。

3.2 EXPLAIN一定要看懂这几个信号

聚合定位到具体模板后，就要对这条SQL做执行计划分析。MySQL里最基础也最常用的命令就是 EXPLAIN：

sql复制EXPLAIN SELECT id, order_no, user_id, amount, status
FROM orders
WHERE status = 2
  AND create_time BETWEEN '2025-03-01 00:00:00' AND '2025-03-31 23:59:59'
ORDER BY id DESC
LIMIT 10;

看执行计划时，别被一堆字段弄花眼，重点看五个地方：

type：访问类型。从好到差大致是 system > const > eq_ref > ref > range > index > ALL。看到 ALL 意味着全表扫描，是最需要警惕的信号。有时候看到 index 也别高兴，它虽然比 ALL 好一点，但仍可能遍历整个索引树，和全表扫描半斤八两。

key：实际使用的索引。如果为 NULL，说明这个查询没有可用索引，基本可以断定是本次慢查询的直接原因。

rows：优化器估计需要扫描的行数。这个值和实际值可能差异很大，但数量级可以作为参考。如果 rows 显示20万而实际表才10万行，说明统计信息存在问题。

filtered：经过WHERE条件过滤后剩余行数的百分比。如果 rows 是100万、filtered是10%，那最终数据大概10万行，仍然很多。filtered很小说明索引条件下推做得不够或者缺少组合索引。

Extra：出现 Using filesort 意味着要额外排序，出现 Using temporary 意味着要建临时表，这两种情况在大数据量下都可能引发性能问题。

在MySQL 8.0.18及以上版本，还可以使用 EXPLAIN ANALYZE 查看实际执行数据：

sql复制EXPLAIN ANALYZE SELECT ...;

它会真实执行这条SQL（这一点要小心，写操作不能用），并输出每个步骤的实际耗时和扫描行数，比普通EXPLAIN基于估计值的输出靠谱得多。

3.3 别全信估算值，统计信息可能骗了你

执行计划里的 rows 只是优化器的估算值。如果表上的统计信息过期，这个估算值会和真实值差出几个数量级，进而导致优化器选错索引。

我自己遇到过最典型的情况是：EXPLAIN 里显示某条SQL预计扫描5万行，选择了索引A；但实际执行要扫300万行，执行时间5秒。这时候我一般会做两件事。

第一件，通过 performance_schema 里的事件明细查到真实执行情况：

sql复制SELECT THREAD_ID, EVENT_NAME, SQL_TEXT,
       ROWS_EXAMINED, ROWS_AFFECTED, TIMER_WAIT/1e12 AS duration_ms
FROM performance_schema.events_statements_history
WHERE SQL_TEXT LIKE '%orders%'
ORDER BY TIMER_WAIT DESC
LIMIT 5;

第二件，开启 optimizer trace 看优化器是怎么做成本决策的：

sql复制SET optimizer_trace = "enabled=on";
SELECT ...; -- 执行真正的慢SQL
SELECT * FROM information_schema.OPTIMIZER_TRACE\G
SET optimizer_trace = "enabled=off";

optimizer trace 会输出优化器对每个可用索引的成本计算过程。看到它因为统计信息偏差而低估或高估了某个索引的成本，你就能理解为什么执行计划会“抽风”。解决办法通常是重新收集统计信息：ANALYZE TABLE orders;。在MySQL 8.0里还可以针对数据分布不均的列维护直方图，帮助优化器更好地估算过滤性。

4. 五个高频慢查询现场：现象、判断与优化动作

4.1 缺索引或者索引被“废掉”

最经典的慢查询现场：某张表有几百万行数据，查询条件里明确写了 WHERE user_id = 123 AND status = 2，但 EXPLAIN 显示 type=ALL、key=NULL。原因可能是根本没建索引，也可能是建了 user_id 的单列索引，但 status 和 CREATE_TIME 还需要回表过滤，导致 MySQL 认为还不如全表扫描。

正确做法是建一个能覆盖查询条件的组合索引：

sql复制ALTER TABLE orders ADD INDEX idx_user_status_time (user_id, status, create_time);

这里有个原则：等值条件放在索引最前面，范围条件放在后面，排序字段也很适合放进索引。这样既能加速过滤，又能避免额外的 filesort。

索引列上做函数操作也容易让索引失效。比如 WHERE DATE(create_time) = '2025-04-01'，虽然 create_time 上有索引，但因为对列套了 DATE 函数，优化器无法走索引范围扫描。改写为：

sql复制WHERE create_time >= '2025-04-01 00:00:00'
  AND create_time < '2025-04-02 00:00:00'

才能用上索引。

4.2 深分页让 LIMIT 变成“深坑”

这类慢查询的特征非常明显：SQL 本身带了很深的 LIMIT 偏移。例如：

sql复制SELECT * FROM orders ORDER BY id LIMIT 100000, 20;

这条SQL看着只要20条数据，但MySQL必须先把前10万行读出来排序，然后丢弃，再返回最后20行。如果表很大，这10万行很可能涉及大量随机IO。

通常有两种优化方向。如果业务场景适合通过上一页最后一条记录的ID来翻页，可以改成游标分页：

sql复制SELECT * FROM orders WHERE id > 100000 ORDER BY id LIMIT 20;

请求必须带一个last_id参数，而不是页码，适合客户端长列表滚动加载的场景。如果产品形态上必须支持跳页，可以用延迟关联：

sql复制SELECT o.*
FROM orders o
INNER JOIN (
    SELECT id FROM orders ORDER BY id LIMIT 100000, 20
) t ON o.id = t.id;

子查询只查主键ID，在二级索引上扫描10万行，比回表扫10万行快得多，拿到20个ID后再回表取完整数据。

4.3 隐式类型转换让索引悄悄失效

还有一种特别隐蔽的索引失效：字段类型和传入参数类型不匹配。比如 orders.user_id 是 varchar(32)，但业务代码里在拼SQL时把 user_id 作为整数传进去，写出来是：

sql复制SELECT * FROM orders WHERE user_id = 20240317;

MySQL会尝试把字符串类型的列转换成数值类型再比较，导致 user_id 列上的索引无法使用，产生全表扫描。这里涉及一个容易混淆的点：如果列是varchar、传入的是数字，MySQL倾向于把列转成数字；如果列是int、传入的是字符串数字，则会把传入值转成数字，可能还有意外情况。经验法则是：SQL参数的类型必须和表结构字段类型保持一致，ORM框架里尤其要检查字段映射。

这种问题最坑的地方在于，平时测试数据量小根本感觉不到差异，等到线上几百万行数据的时候突然变成慢查询，然后 DBA 一脸懵：索引明明建了，为什么不用？

4.4 Lock_time 占大头：被阻塞的查询也会进慢日志

有些慢查询，SQL写法没问题，索引也没问题，但日志里 Query_time 就是好几秒。这时候一定要看 Lock_time。

比如这条：

text复制# Query_time: 10.211752  Lock_time: 9.858392 Rows_sent: 1  Rows_examined: 1

Rows_examined 只有1，说明这条查询本身几乎没做任何事，9.8秒全花在等锁上。这类问题的根源通常不在SQL，而在其他事务持锁时间过长。

排查方法可以先看当前是否有事务在跑，持锁时间多久：

sql复制SELECT trx_id, trx_state, trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS trx_running_seconds,
       trx_mysql_thread_id
FROM information_schema.innodb_trx
ORDER BY trx_started;

再看是否有表级锁等待：

sql复制SELECT * FROM sys.schema_table_lock_waits\G

锁等待这类慢查询，优化思路要往上走一层：检查业务是不是在一个事务里做了外部API调用、大文件处理或者批量循环更新。事务里不该有耗时的非数据库操作。行锁竞争严重的表，还要考虑能不能把大事务拆小、把更新操作涉及的行数降下来，减少锁的范围。

4.5 执行计划漂移：同样一条SQL白天快夜里慢

某条SQL在业务低峰期执行只要200ms，一到高峰期反而要5秒。这种场景通常不是查询本身的问题，而是优化器在不同时段选了不同的执行计划。数据量增大、统计信息更新、甚至InnoDB缓冲池里缓存的数据变化，都可能影响执行计划的选择。

这类问题用前面提到的V/M指标能提前发现。临时对策是在SQL里加索引提示先止血：

sql复制SELECT * FROM orders FORCE INDEX (idx_user_status_time) WHERE ...

但 FORCE INDEX 只是权宜之计，因为一旦索引名变更SQL就失效，而且它把优化器的决策权拿走了，后续数据分布再次变化时反而可能帮倒忙。长期对策一般是：重新收集统计信息（ANALYZE TABLE），或者调整索引设计，把冗余的、区分度差的索引删掉，减少优化器选错的概率。有时候一张表上五六个单列索引，看着每个都有用，实际会让优化器在成本估算时“挑花眼”。

5. 从单条SQL到整库的监控体系：指标分层与告警设计

5.1 指标要分三个层次来看

我建议把数据库监控指标分成三层，这样告警和排障时思路会清晰很多。

很多团队的问题在于只建了前两层，最关键的第三层缺失。没有语句层指标，系统层和数据库层告警只能告诉你“数据库压力大”，但无法告诉你压力来自哪条具体的SQL。而有语句层指标之后，资源指标异常时可以直接和SQL模板关联，形成一条完整的证据链：CPU打满 → 慢查询次数上升 → 某个SQL模板扫描行数暴增 → 定位到具体业务SQL。

5.2 用performance_schema做实时SQL审计

前面提到过性能分析工具 pt-query-digest 适合离线分析，不适合实时监控。想要做到实时，就得靠 performance_schema 里的聚合表。

举个例子，查看当前耗时最长的SQL模板：

sql复制SELECT SCHEMA_NAME,
       DIGEST_TEXT,
       COUNT_STAR,
       ROUND(AVG_TIMER_WAIT / 1e12, 2) AS avg_ms,
       ROUND(MAX_TIMER_WAIT / 1e12, 2) AS max_ms,
       ROUND(SUM_ROWS_EXAMINED / COUNT_STAR) AS avg_rows_examined
FROM performance_schema.events_statements_summary_by_digest
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 20;

这张表的粒度是按SQL模板聚合的，能实时反映每个模板的执行次数、平均耗时、最大耗时、平均扫描行数。配合Prometheus这类监控系统定期抓取，就能画出“某个SQL模板平均耗时随时间变化”的曲线。当曲线开始抬头时，即使还没超阈值，也可以提前介入。

mysqld_exporter 本身就暴露了相关指标，原理就是从 events_statements_summary_by_digest 等 performance_schema 表读取数据后转换格式。在Grafana里可以做成这样的面板：按Query ID或Digest Text展示TOP 10慢SQL，趋势、耗时、扫描行数一目了然。

5.3 告警规则怎么设计才不会被“狼来了”淹没

做数据库监控，最忌讳的就是每条慢查询都发一条告警。如果 slow_query_log 的阈值是1秒，一个业务高峰线上每秒可能有几十条SQL超过1秒，告警能刷屏刷到大家直接把群屏蔽。等到真正出大事时，反而没人响应了。

我个人的经验是，告警规则要基于基线和趋势，而不是固定阈值。比如：

Warning级：最近5分钟慢查询总数超过过去7天同一时间窗口平均值的3倍。这个规则能捕捉到“异常突增”，又不会因为平时稳定的小流量慢SQL而反复打扰。

Critical级：数据库活跃会话数超过连接池上限的80%，且慢查询总数同步上升。两个条件同时满足才触发最高级别告警，因为这时候才说明慢查询已经影响到系统的整体吞吐，需要立刻处理。

对于少数核心业务库，可以玩得更细：单独挑出最重要的几张表，任何针对它们的慢查询超过3秒就直接告警，不管总数多寡。核心链路和非核心链路分开设阈值，比全库一个规则科学得多。

告警消息里也应该带更多上下文，比如实例地址、SQL模板摘要、最近一次执行耗时和扫描行数。好的告警不是告诉人“系统慢了”，而是直接告诉人“在哪个实例上，哪条SQL慢，扫描了多少行，出现了多少次”，这样处理效率能提高一倍。

6. 慢查询监控的边界与几个容易栽跟头的点

讲到这里，慢查询分析的主线基本清楚了。但实践多次后你会发现，慢查询监控也有它自己的局限性，还有一些容易踩的坑值得单独拿出来说。

第一，不要把所有慢查询优化任务都压在“慢日志”上。慢日志只能记录执行时间超过阈值的SQL，但那些执行很快、却在高频调用下吃满CPU的SQL不会出现在慢日志里。你可能慢查询一天只有几十条，数据库压力却很大。这时候要结合performance_schema按执行总耗时或总扫描行数排序，找出“累计资源消耗最大”的SQL模板，而不是只看单次执行时间。

第二，慢查询分析解决的是“SQL执行效率”问题，但数据库监控里还有一类问题它覆盖不到：即时会话阻塞。当某条SQL卡在锁等待中时，慢日志可能要到执行结束后才落一条记录，现场已经过去了。需要依赖 show processlist 和 performance_schema 里的实时等待事件，才能抓到正在发生的锁等待链条。慢查询分析更偏向事后复盘和趋势发现，实时故障的处置要另外配套方法论。

第三，刚接触慢查询优化的人容易犯一个毛病：把 long_query_time 调得很低，比如0.1秒甚至0，结果慢日志文件每小时涨好几个GB，不但浪费磁盘，还拖慢数据库IO。低阈值不是不能用，但要用对地方：可以在压测环境开0.1秒抓全量SQL，生产环境还是建议先从1秒起，配合log_queries_not_using_indexes抓“未用索引但还不慢”的潜在问题。真正想全面掌握SQL质量，建议直接查performance_schema，就别太依赖低阈值日志了。

第四，把慢查询次数本身作为KPI去驱动优化，会有一个副作用：团队可能通过不断调高 long_query_time 来让慢查询数量“变少”。这就失去了监控的意义。我习惯用“同一条路径在相同数据规模下耗时是否下降”来看优化效果，或者看某个核心SQL模板的扫描行数是否降了一个量级，而不只是盯着总数。

最后分享一个我自己的巡检习惯：每天早上到公司的第一件事，不是看CPU和连接数，而是花两分钟看一眼前一天的慢查询聚合报告。哪几个SQL模板新出现了，哪个老模板的执行频率在悄悄变高，数据量增长最快的表是哪几张。慢查询是数据库里最先暴露问题的侦察兵，它往往比硬件告警和连接数异常提前几天甚至几周向你发出信号，只是大多数人习惯把注意力放在那些更响亮的告警上，忽略了这条已经存在于日志里的线索。先把慢查询这块管起来，再去折腾那些漂亮的监控大屏，你会发现自己离真正的数据库性能问题更近了。