MySQL performance_schema 语句历史怎么抓：按 digest 定位异常 SQL

线上接口突然变慢的时候，慢日志不一定能直接给到完整的故障现场：有的语句只执行过一次，有的只是参数不同本质上属于同一类请求。MySQL 的 performance_schema 可以留存近期的语句事件，DIGEST 还会把语句里的字面量做归一化处理，排查过程直接从“猜哪条SQL出问题”变成“先定位哪类SQL正在占资源”，效率高很多。

排查近期异常 SQL，先看 events_statements_history_long 的事件记录和耗时数据，再按 DIGEST 做聚合统计；如果发现历史表为空或者记录被覆盖了，千万别直接把“没查到记录”判定成“没有问题”。

先分清两张语句历史表

MySQL 提供的语句事件表不是可以无限增长的审计表。当前会话、线程历史和全局历史分别覆盖不同的统计范围；这里重点讲全局的 events_statements_history_long，它按线程维度收集最近完成的语句，快速就能查到“刚才实例上跑过什么请求”。

用一条查询捞出最近的高耗时语句

先直接查询全局历史记录，不用一上来就做复杂的聚合操作：

SELECT THREAD_ID,
       EVENT_ID,
       EVENT_NAME,
       SQL_TEXT,
       TIMER_WAIT,
       ROWS_EXAMINED,
       ROWS_AFFECTED,
       CURRENT_SCHEMA
FROM performance_schema.events_statements_history_long
WHERE SQL_TEXT IS NOT NULL
ORDER BY TIMER_WAIT DESC
LIMIT 20;

TIMER_WAIT 用的是皮秒作为计数单位，页面展示的时候可以换算成更易懂的毫秒单位：

SELECT ROUND(TIMER_WAIT / 1000000000, 2) AS latency_ms,
       ROWS_EXAMINED,
       ROWS_AFFECTED,
       SQL_TEXT
FROM performance_schema.events_statements_history_long
WHERE SQL_TEXT IS NOT NULL
ORDER BY TIMER_WAIT DESC
LIMIT 20;

这里的排序结果只代表采样表里记录到的“最慢的近期事件”，它不是全量历史数据，也不能直接当成接口的P99耗时指标；先把它当成现场线索，再回到应用日志里确认对应的请求链路就好。

按 DIGEST 找出真正的 SQL 热点

同一条订单查询可能带着不同的 user_id 和查询日期。如果直接按原始SQL文本分组统计，会得到大量看起来完全不同的记录。语句摘要表中的 DIGEST 和 DIGEST_TEXT 可以把这些本质相同的语句自动归并到一起：

SELECT DIGEST,
       DIGEST_TEXT,
       COUNT_STAR,
       ROUND(SUM_TIMER_WAIT / 1000000000, 2) AS total_ms,
       ROUND(AVG_TIMER_WAIT / 1000000000, 2) AS avg_ms,
       SUM_ROWS_EXAMINED,
       SUM_ROWS_AFFECTED
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST_TEXT IS NOT NULL
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 20;

COUNT_STAR 是语句的执行次数，SUM_TIMER_WAIT 适合找总资源消耗最高的语句，AVG_TIMER_WAIT 适合找单次执行就很慢的语句。有些SQL单次执行很快但调用次数极多，最终占用的实例资源总量反而远高于只出现一次的慢SQL，这类问题优先级通常会更高。

没有结果时先检查采集开关和容量

如果查询发现历史表是空的，先核对基础配置项：

SELECT NAME, ENABLED, TIMED
FROM performance_schema.setup_instruments
WHERE NAME LIKE 'statement/%'
ORDER BY NAME;

SELECT *
FROM performance_schema.setup_consumers
WHERE NAME LIKE '%statements%';

不同版本的MySQL，相关consumer的名称可能会有细微差别，所以先以当前实例实际返回的名称为准。之后再确认目标表确实存在、当前服务账号有查询权限，同时确认问题发生之后间隔的时间没有太久，导致历史记录已经被新事件覆盖掉了。

历史表本质是环形缓冲区，不是永久存储的仓库。实例重启、采集开关变更、事件数量超过预设容量，都会让之前的旧现场消失。碰到需要跨小时甚至跨天对比的问题，要把摘要指标同步导出到慢日志、监控系统或者自己写的定时采集脚本里留存。

用三个字段判断排查优先级

1. 总耗时：先看 SUM_TIMER_WAIT，它能反映某类SQL对实例CPU和IO时间的总消耗量。
2. 单次耗时：再看 AVG_TIMER_WAIT，识别单次请求就很慢的执行计划或者锁等待问题。
3. 扫描放大：把 SUM_ROWS_EXAMINED 与 COUNT_STAR 对照，平均扫描行数明显大于最终返回结果行数的时候，再进一步分析索引合理性、过滤条件效率和数据分布情况。

常见问题

events_statements_history_long 能查到昨天的 SQL 吗？

没办法保证。它只会保留有限数量的近期事件，配置的容量大小和实例运行状态都会影响能覆盖的时间范围。

TIMER_WAIT 为什么看起来数值特别大？

它的单位不是毫秒，是皮秒计数。查询的时候除以 1000000000 才能换算成毫秒单位。

DIGEST_TEXT 会保留每次执行的实际参数吗？

不会。它的作用是归并同类语句，每次执行的具体入参还是要结合应用日志或者原始事件文本来确认。

让“查不到现场”也变成可解释结果

performance_schema 的价值不在于保存全量所有SQL，而是给故障排查提供一段可直接查询的近场证据：先从事件历史里确认有没有真的出现过异常，再用 DIGEST 聚合同类负载，最后用慢日志和应用指标补全缺失的时间范围。摸透这套机制的边界之后，查到空结果也不是毫无意义的结论，而是提醒你去检查采样窗口、容量配置和持续采集链路有没有出问题。