MySQL STATEMENT_DIGEST_TEXT 为什么出现省略号

MySQL STATEMENT_DIGEST_TEXT 返回的内容出现省略标记或尾部缺失时，要先区分列表归约、摘要计算长度限制和客户端显示截断。其中 max_digest_length 限制摘要计算可用的空间；长语句耗尽空间后，后续 token 不再参与摘要。省略号本身不能单独证明 SQL 没有执行完整，也不能作为所有截断情况的唯一判断标准。

官方文档地址：https://dev.mysql.com/doc/refman/8.4/en/

识别尾部截断与列表归约

摘要是便于统计的规范化表示，并不是原 SQL 的完整副本。参数列表可能被归约成更紧凑的表示；若省略标记出现在列表内部，而列表后的结构还存在，应先考虑归约。长语句的后半段整体消失，则要进一步查看长度限制。若数据库返回值完整、界面只展示前几百个字符，问题发生在展示层。

尤其在迁移实例或更换 SQL 客户端后，别把所有文本差异都当成服务器版本回归。先保存完整返回值、原始输入以及两边配置，才能定位具体差异。本文以 MySQL 8.4 文档的长度规则为范围，不假定某个升级版本必然改变默认值。

读取摘要长度配置

先运行只读查询，记录服务器版本、摘要计算上限和 Performance Schema 保存上限。函数使用解析器生成摘要，而 Performance Schema 可以在保存副本时进一步截断，两项参数不能互相代替。

-- 在源实例和目标实例分别保存这些值，避免只比较版本号。
SELECT VERSION() AS server_version,
       @@GLOBAL.max_digest_length AS parser_digest_bytes,
       @@GLOBAL.performance_schema_max_digest_length AS stored_digest_bytes;

MySQL 8.4 文档将 max_digest_length 列为全局、非动态、按字节计的参数，默认值为 1024。它涉及每个会话的摘要计算空间；不能通过普通会话 SET 立即调整。字节限制也不等于客户端看到的字符数，内部编码和展示形式会影响长度解释。

用长标识符构造受控示例

测试长度限制时，单纯把某个字符串字面值拉长不理想，因为字面值会被规范化。可以使用合法的长别名构造较长 token 序列，让列表后的尾部条件作为观察点。下面的语句只把 SQL 字符串交给摘要函数，不执行字符串中的查询，也不创建数据表。

-- 别名不同且足够长，减少重复字面值归约对观察的干扰。
SET @sql_sample = CONCAT(
  'SELECT ',
  '1 AS ', REPEAT('a', 60), ', ',
  '2 AS ', REPEAT('b', 60), ', ',
  '3 AS ', REPEAT('c', 60), ', ',
  '4 AS ', REPEAT('d', 60), ', ',
  '5 AS ', REPEAT('e', 60), ', ',
  '6 AS ', REPEAT('f', 60), ', ',
  '7 AS ', REPEAT('g', 60), ', ',
  '8 AS ', REPEAT('h', 60), ', ',
  '9 AS ', REPEAT('i', 60), ', ',
  '10 AS ', REPEAT('j', 60), ', ',
  '11 AS ', REPEAT('k', 60), ', ',
  '12 AS ', REPEAT('l', 60), ', ',
  '13 AS ', REPEAT('m', 60), ', ',
  '14 AS ', REPEAT('n', 60), ', ',
  '15 AS ', REPEAT('o', 60), ', ',
  '16 AS ', REPEAT('p', 60), ', ',
  '17 AS ', REPEAT('q', 60), ', ',
  '18 AS ', REPEAT('r', 60),
  ' FROM sample_orders WHERE tail_marker = 71'
);
-- 保存完整摘要及其字节数；不要仅看客户端单元格预览。
SET @digest_text = STATEMENT_DIGEST_TEXT(@sql_sample);
SELECT LENGTH(@sql_sample) AS input_bytes,
       LENGTH(@digest_text) AS digest_bytes,
       @digest_text AS digest_text,
       STATEMENT_DIGEST(@sql_sample) AS digest_hash;

观察尾部表名和 tail_marker 条件是否还在；若已在计算阶段截断，就不能依靠摘要恢复丢失的尾部。示例是否触及上限取决于实例配置，不应把示例输出写成所有环境都固定出现的结果。本文不提供虚构的本机执行截图或实测数值。

比较迁移前后的配置和摘要

先在两边用相同 SQL 样本和相同连接设置执行上面的查询，再记录完整结果。如果 max_digest_length 不同，应先解释配置差异，再讨论版本行为。改变上限可能让过去在尾部才有区别的语句产生不同摘要，所以依赖摘要作为长期键的监控数据不能直接假定跨配置稳定。

需要调大上限时，将其纳入启动配置与维护安排，而不是在线反复尝试 SET。按连接数量评估会话计算空间，同时考虑 Performance Schema 中多条语句副本的占用。仅调大保存上限无法补回解析器早已丢弃的 token；仅调大计算上限也不保证表中的文本副本完整。

调整不会重新生成已经保存的历史摘要。迁移前留存原 SQL 样本和配置快照，调整后用新采集的数据比较；监控系统应记录配置切换时间，避免把摘要分组变化误读成业务 SQL 突然增多。

整理常见问题与变更清单

没有省略号就说明摘要完整吗？不能。应结合输入结构、尾部标识符、配置和完整返回值判断，不要只检查最后三个字符。客户端显示和服务端摘要截断也需要分开看。

相同摘要哈希是否证明原 SQL 完全相同？不能。规范化会抹去部分字面信息，计算长度限制还可能让只在被截掉的尾部不同的语句得到相同摘要。摘要用于结构统计，不是原文等同性证明。

截断摘要能否恢复原 SQL？不能从摘要反向还原被移除的内容。排障时另外保存允许留存的原 SQL 样本；Performance Schema 的 SQL_TEXT 等样本字段也有各自的保存长度限制。

变更记录至少保留版本、两个摘要长度参数、同一输入样本、完整函数返回值及新采集时间。先识别归约或截断，再决定是否调整启动配置，最后解释统计分组变化。

参考：MySQL 摘要函数；max_digest_length 参数；摘要计算与保存机制。