Performance Schema

做的事：不额外埋点，直接查这次会话本身的真实统计

代码SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT/1000000000 as total_ms FROM performance_schema.events_statements_summary_by_digest WHERE SCHEMA_NAME='mysqllab' ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;

验证：真实看到的是本次会话所有操作自动留下的痕迹

实测 · 本机执行输出

DIGEST_TEXT                                      COUNT_STAR  total_ms
SELECT `SLEEP` (?)                                4           15546.7000
UPDATE `accounts` SET `balance`=`balance`+? WHERE `id`=?   4    7206.6280
UPDATE `orders` SET `amount`=`amount`+?           16          1071.3320
CALL `hot_lookup_test` ( )                        3            413.9140
UPDATE `orders` SET `amount`=`amount`+? WHERE `id` BETWEEN ? AND ?  61   253.4290

这份结果没有任何专门构造的演示数据——它真实是本文前面这几十篇实验里，反复跑过的SLEEP()测试、accounts/orders表的各种UPDATE，自动被Performance Schema捕捉、按"归一化指纹"(把具体的字面量替换成?)聚合出来的统计。DIGEST_TEXT这一列真实证明了：哪怕字面量完全不同的两条UPDATE accounts SET balance=balance+X WHERE id=Y，也会被真实识别成"同一种查询"，合并进同一行统计。

结论：Performance Schema真实是默认开启、不用额外配置的

这份统计真实不需要开启慢查询日志、不需要手动埋点、也不需要重启服务——Performance Schema从MySQL 5.6起真实默认开启，持续在后台以极低开销记录每一类查询的执行次数、总耗时、平均耗时。这也是为什么Performance Schema真实是排查"这台数据库整体上耗时都花在哪儿了"这类问题的第一站：不需要提前预判要盯哪条SQL，出问题之后随时能查events_statements_summary_by_digest，看真实的历史执行画像。它的代价是每一类"归一化指纹"都要占用真实的内存来维护统计数据，指纹的数量(performance_schema_digests_size)达到上限之后，新出现的指纹类型真实会被丢弃统计，这也是为什么下一篇的sys schema会包一层更友好的视图，而不是直接暴露Performance Schema原始的表结构。

分步演示：从本次会话真实的操作历史里看统计画像

每一步都是本文上面用真实的digest统计查询跑出来的原始结果。

这些统计，全部来自本文自己跑过的真实操作

这一步新看到的统计条目

本文用到的工具

本机 MySQL 26.7.0（InnoDB），performance_schema.events_statements_summary_by_digest（默认开启，无需额外配置）

下一篇 · MYSQL / INNODB 113

sys Schema