跑5条id字面量不同的SELECT,用performance_schema.events_statements_summary_by_digest验证它们被归并成同一条语句摘要。
场景里,同一条SQL模板会带着不同的参数值被执行成千上万次。
代码for i in [1,2,3,4,5]: SELECT * FROM t10 WHERE id = {i} -- 每次的字面量都不同
查performance_schema里的摘要表。
结果SELECT DIGEST_TEXT, COUNT_STAR FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%t10%' → DIGEST_TEXT: SELECT * FROM `t10` WHERE `id` = ? → COUNT_STAR: 5
结果里,5条WHERE后面字面量各不相同的SELECT语句(id=1到id=5),全部被归并成了同一条摘要,字面量被统一替换成了 ? 占位符,COUNT_STAR 精确记录着这条"语句模板"被执行了5次。
这就是"语句摘要"(statement digest)解决的问题。
如果没有digest归并,慢查询日志里1万次"同一类查询、参数不同"的记录,要一条条去看、去数,很难一眼看出"这一类查询平均耗时多少、总共占了多少资源"。performance_schema 把SQL文本里的字面量常量抹掉,只保留语句的"形状",用这个形状做key做的聚合统计——同一形状的语句不管参数值差多少、跑了多少次,最终都能在一行摘要记录里看到总执行次数、平均耗时、总扫描行数等统计信息,这是排查"到底是哪一类SQL在拖慢整个库"最直接的入口。
每一步都是本文上面用MySQL跑出来的原始结果。
performance_schema.events_statements_summary_by_digest:验证语句归并统计