INNODB_TRX 表不提供 Undo 大小字段，因其设计目标是反映事务状态（如 trx_state、trx_started），而非实时映射异步管理的 Undo 空间消耗；Undo 段实际占用受修改行数、操作类型、大字段及历史读视图等多因素影响，无法在行级精确量化。
直接查不到单个事务占用的Undo段精确字节数，INNODB_TRX 表只提供事务元信息，不暴露Undo空间消耗量。
为什么 INNODB_TRX 里没有 Undo 大小字段
MySQL 的 information_schema.INNODB_TRX 表设计目标是反映事务状态（如 trx_state、trx_started、trx_mysql_thread_id），而非存储资源占用细节。Undo 段的分配、使用和释放由 InnoDB 内部异步管理，其实际空间消耗无法在事务行级实时映射为一个可查询的数值。
-
trx_rows_modified可间接提示修改量，但不等于 Undo 占用——比如大字段更新可能产生远超行数的 Undo 记录 -
trx_isolation_level影响 Undo 保留时长（REPEATABLE READ下更久），但不体现当前大小 - 即使事务已提交，Undo 仍可能被其他活跃读视图引用，
INNODB_TRX中已无该事务记录，但空间未释放
真正能反映 Undo 段压力的替代指标
要评估“未提交事务对 Undo 的实际挤压程度”，应组合以下三类观测点：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 查长事务本身：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_started —— 找出运行超 10 分钟的事务，它们极可能是 Undo 积压源头 - 看全局 History 列表长度：
SHOW ENGINE INNODB STATUS\G输出中关注History list length值；若持续 > 5000，说明已提交事务的 Undo 正在堆积，大概率因上述长事务阻塞 purge - 确认 Undo 文件物理增长：
ls -lh /var/lib/mysql/undo*（路径以innodb_undo_directory配置为准）；若undo_001等文件长期不缩且单个超 2GB，基本可判定 Undo 清理链路卡住
想估算某事务 Undo 开销？只能靠间接推断
没有现成 SQL 能返回 “线程 123 当前 Undo 占用 XX KB”，但可通过如下方式做合理推测：
- 检查该事务修改了哪些表：
SELECT * FROM information_schema.INNODB_TRX t JOIN information_schema.INNODB_LOCK_WAITS w ON t.trx_id = w.blocking_trx_id;结合锁等待关系定位热点表 - 估算表平均行 Undo 成本：一次
UPDATE通常生成约 20–50 字节 Undo 记录（不含大字段），DELETE约 30–80 字节；若事务已修改 10 万行，粗略下限就是 2MB+ - 观察
VARIABLES中innodb_undo_log_truncate是否启用：若关闭，Undo 文件只增不缩，历史积压会放大单个长事务的实际影响
真正棘手的不是“怎么查大小”，而是“查到长事务后不敢 KILL”——因为应用层可能依赖其事务上下文。与其纠结某个数字，不如盯住 History list length 和文件系统增长趋势，它们才是 Undo 压力是否失控的硬信号。
