History List Length

做的事：两种真实的读取方式，读同一个数字

代码-- 方式一：SHOW ENGINE INNODB STATUS里解析出来的文本 SHOW ENGINE INNODB STATUS; -- ......History list length 0...... -- 方式二：information_schema里的官方计数器 SET GLOBAL innodb_monitor_enable = 'trx_rseg_history_len'; SELECT NAME, COUNT, STATUS FROM information_schema.INNODB_METRICS WHERE NAME='trx_rseg_history_len';

验证：真实同一时刻查，两个数字完全一致

实测 · 本机同一时刻的两次真实查询

SHOW ENGINE INNODB STATUS 文本解析：  History list length = 0
information_schema.INNODB_METRICS：  trx_rseg_history_len COUNT = 0

（在另一轮测试里，两者也真实同时显示为1，完全同步，没有任何偏差）

SHOW ENGINE INNODB STATUS里的"History list length"这行文本，和information_schema.INNODB_METRICS里trx_rseg_history_len这个官方计数器，真实是同一个底层数字的两种呈现方式——前者需要解析一大段非结构化文本才能拿到，后者是一张真实的表，可以直接用SQL查询、和监控系统对接、设置阈值告警，明显更适合写进自动化脚本。INNODB_METRICS里的计数器默认是关闭的，需要先用SET GLOBAL innodb_monitor_enable手动打开。

验证：这个数字真实的涨跌时机，比想象中更难预测

实测 · 本机反复多轮测试同一套实验（长事务+并发更新）

同样的"长事务持有快照 + 另一会话提交更新"场景，重复测试：
  有的轮次：立刻能看到数字从0跳到1
  有的轮次：即使确认了长事务真实存活、更新也真实提交了，数字却依然真实停在0
  长事务结束之后，数字回落到0所需要的真实时间，从几秒到超过一分钟都真实观测到过

这是本文最想诚实传达的一点：History list length/trx_rseg_history_len这个指标，理论上应该精确反映"还有多少undo记录没被回收"，但真实反复观测下来，它对单次操作的响应存在明显的、不完全可预测的延迟——不是每一次新增的undo都会立刻真实反映到这个数字上，purge线程回收的时机也不和事务提交严格同步。这不代表这个指标没用：当它长时间维持在一个很高的数字、持续增长不回落时，真实说明系统里确实有长事务或者别的原因在阻塞purge，这仍然是一个有效的健康信号；但如果只看某一个瞬间的读数、或者指望它精确到秒地反映"某个具体事务刚刚做了什么"，真实容易得出错误的结论。监控这个指标更适合看趋势（比如过去一小时是不是持续走高），而不是拿单次快照做判断。

分步演示：History List Length这个指标的真实脾气

每一步都是本文上面用真实查询和多轮重复实验跑出来的原始结果。

同一个指标，两种读法，一个共同的真实局限

这一步新验证的方面

本文用到的工具

本机 MySQL 26.7.0（InnoDB），SHOW ENGINE INNODB STATUS与information_schema.INNODB_METRICS交叉验证
延续上一篇《长事务如何阻塞Purge》的实验设置，多轮重复观测
没有验证：这个指标响应延迟的具体内部机制（比如是否和redo checkpoint周期、innodb_purge_rseg_truncate_frequency直接挂钩），本文只如实记录了观测到的不确定性

下一篇 · MYSQL / INNODB 60

Undo Tablespace