当解析器收到 SQL 语句时，如果需要该摘要，它会计算一个语句摘要，如果以下任何条件为真，则为真：

max_digest_length系统变量值确定每个会话可用于计算规范化语句摘要的最大字节数 。一旦在摘要计算期间使用了该数量的空间，就会发生截断：不再收集来自已解析语句的标记或将其计入其摘要值。仅在许多字节的已解析令牌产生相同的规范化语句摘要之后才不同的语句，如果进行比较或汇总以获取摘要统计信息，则这些语句被认为是相同的。

在计算出规范化语句后，从中计算出一个 MD5 散列值。此外：

语句规范化将语句文本转换为更标准化的摘要字符串表示形式，该表示形式保留了一般语句结构，同时删除了对该结构不重要的信息：

考虑这些陈述：

SELECT * FROM orders WHERE customer_id=10 AND quantity>20
SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100

为了规范化这些语句，解析器用空格替换数据值?并调整空格。两个语句产生相同的规范化形式，因此被认为是 “相同的”：

SELECT * FROM orders WHERE customer_id = ? AND quantity > ?

规范化语句包含的信息较少，但仍代表原始语句。具有不同数据值的其他类似语句具有相同的规范化形式。

现在考虑这些陈述：

SELECT * FROM customers WHERE customer_id = 1000
SELECT * FROM orders WHERE customer_id = 1000

在这种情况下，规范化语句不同，因为对象标识符不同：

SELECT * FROM customers WHERE customer_id = ?
SELECT * FROM orders WHERE customer_id = ?

如果规范化生成的语句超出摘要缓冲区中的可用空间（由确定 max_digest_length），则会发生截断并且文本以“ ... ”结尾。仅在“ ... ”之后出现的部分不同的长规范化语句被认为是相同的。考虑这些陈述：

SELECT * FROM mytable WHERE cola = 10 AND colb = 20
SELECT * FROM mytable WHERE cola = 10 AND colc = 20

如果截断恰好在 之后 AND，则两个语句都具有以下规范化形式：

SELECT * FROM mytable WHERE cola = ? AND ...

在这种情况下，第二列名称中的差异将丢失，并且两个语句被认为是相同的。

在 Performance Schema 中，语句摘要涉及这些元素：

语句事件表还有一 SQL_TEXT列包含原始 SQL 语句。默认情况下，语句显示的最大可用空间为 1024 字节。要更改此值，请 performance_schema_max_sql_text_length 在服务器启动时设置系统变量。

performance_schema_max_digest_length 系统变量确定性能模式中摘要值存储的每个语句可用的最大字节数 。 但是，由于关键字和文字值等语句元素的内部编码，语句摘要的显示长度可能比可用缓冲区大小长。因此，从 DIGEST_TEXT语句事件表的列中选择的值可能看起来超过该 performance_schema_max_digest_length 值。

摘要 events_statements_summary_by_digest 表提供了服务器执行的语句的配置文件。它显示了应用程序正在执行的语句类型以及执行频率。应用程序开发人员可以使用此信息以及表中的其他信息来评估应用程序的性能特征。例如，显示等待时间、锁定时间或索引使用情况的表列可能会突出显示效率低下的查询类型。这使开发人员可以深入了解应用程序的哪些部分需要注意。

汇总表 events_statements_summary_by_digest 具有固定大小。默认情况下，性能模式估计启动时使用的大小。要明确指定表大小，请 performance_schema_digests_size 在服务器启动时设置系统变量。如果表已满，则性能模式会将具有 SCHEMA_NAME和DIGEST 值与表中现有值不匹配的语句分组在特殊行中SCHEMA_NAME并 DIGEST设置为NULL。这允许计算所有语句。但是，如果特殊行占执行语句的很大百分比，则可能需要通过增加 来增加摘要表的大小 performance_schema_digests_size。

对于生成仅在末尾不同的非常长的语句的应用程序，增加 max_digest_length可以计算摘要以区分否则会聚合到同一摘要的语句。相反，减少 max_digest_length会导致服务器将更少的内存用于摘要存储，但会增加较长语句聚合到同一摘要的可能性。管理员应该记住，较大的值会导致相应增加的内存需求，特别是对于涉及大量同时会话的工作负载（服务器 max_digest_length为每个会话分配字节）。

如前所述，由解析器计算的规范化语句摘要被限制为最大 max_digest_length字节数，而存储在性能模式中的规范化语句摘要使用 performance_schema_max_digest_length 字节。以下内存使用注意事项适用于 max_digest_length和 的相对值performance_schema_max_digest_length：

因为 Performance Schema 语句事件表可能存储许多摘要，所以设置 performance_schema_max_digest_length 小于max_digest_length 使管理员能够平衡这些因素：

该 performance_schema_max_digest_length 设置不是每个会话，它是每个语句，一个会话可以在 events_statements_history表中存储多个语句。此表中的典型语句数是每个会话 10 个，因此每个会话 performance_schema_max_digest_length 仅针对此表消耗 10 倍的值所指示的内存。

此外，在全球范围内收集了许多声明（和摘要），最显着的是在 events_statements_history_long 表中。在这里，N存储的语句也消耗了值N所指示的内存的倍数 performance_schema_max_digest_length 。

要评估用于 SQL 语句存储和摘要计算的内存量，请使用 SHOW ENGINE PERFORMANCE_SCHEMA STATUS语句或监控这些工具：

mysql> SELECT NAME
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE '%.sqltext';
+------------------------------------------------------------------+
| NAME                                                             |
+------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.sqltext      |
| memory/performance_schema/events_statements_current.sqltext      |
| memory/performance_schema/events_statements_history_long.sqltext |
+------------------------------------------------------------------+

mysql> SELECT NAME
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'memory/performance_schema/%.tokens';
+----------------------------------------------------------------------+
| NAME                                                                 |
+----------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.tokens           |
| memory/performance_schema/events_statements_current.tokens           |
| memory/performance_schema/events_statements_summary_by_digest.tokens |
| memory/performance_schema/events_statements_history_long.tokens      |
+----------------------------------------------------------------------+