MySQL undo 日志为二进制逻辑日志，需通过 INNODB_TRX、INNODB_STATUS、系统变量、FILES 表及 Performance Schema 等间接观测其状态、配置、使用与压力。
MySQL 的 undo 日志本身是二进制、内部结构化的逻辑日志，不能像文本日志那样直接 cat 或 vi 查看。但你可以通过系统表、状态信息和配置参数，间接观察 undo 的存在、使用状态、活跃事务回滚行为及潜在问题。
查当前活跃事务与回滚状态
这是最直接反映“是否正在回滚”以及“谁在占用 undo”的方式：
- 运行
SELECT * FROM information_schema.INNODB_TRX;，重点关注trx_state字段：若值为ROLLING BACK，说明该事务正处于回滚中；trx_started时间过早则可能卡住。 - 配合
SHOW ENGINE INNODB STATUSG，在输出的 TRANSACTIONS 部分查找ROLLING BACK关键字，并注意其后列出的线程 ID 和剩余操作数（如“undo n to do”）。 - 若发现长时间 ROLLING BACK，通常意味着修改了大量数据（如全表 UPDATE/DELETE），或磁盘 I/O 延迟高，需结合
PROCESSLIST查看对应线程执行的 SQL。
查 undo 表空间配置与文件位置
了解 undo 是否独立存放、有几个文件、路径在哪，是分析容量和清理能力的基础：
-
SHOW VARIABLES LIKE 'innodb_undo_directory';—— 查看 undo 文件实际存放目录（默认同datadir）。 -
SHOW VARIABLES LIKE 'innodb_undo_tablespaces';—— 返回数字（如 2），表示启用了几个独立 undo 表空间（MySQL 5.6+ 支持，默认为 0 表示用系统表空间）。 -
SELECT NAME, SPACE_TYPE, FILE_NAME FROM information_schema.FILES WHERE SPACE_TYPE = 'Undo';—— 直接列出所有 undo 表空间文件名及路径，适用于 MySQL 8.0+。
查 undo 使用情况与长事务影响
undo 不会无限保留——已提交事务的 undo 由 purge 线程异步清理，但前提是“没有活跃读视图”依赖它（比如长事务未提交）。因此：
- 查长事务：
SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5;，找trx_started早于 10 分钟以上的事务。 - 查 purge 滞后迹象：在
SHOW ENGINE INNODB STATUSG输出中，关注 HISTORY LIST 数值（如“History list length 124500”），数值持续增长且 > 10000，往往说明 purge 跟不上，undo 积压。 - 操作系统 层面检查文件大小：
ls -lh /var/lib/mysql/undo*（路径以innodb_undo_directory为准），若单个文件超几 GB 且长期不缩，需警惕。
查 undo 相关监控指标（MySQL 8.0+）
借助 Performance Schema 可量化评估 undo 压力：
-
SELECT * FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%rollback%';—— 统计应用端显式执行 ROLLBACK 的频次。 -
SELECT NAME, COUNT_STAR FROM performance_schema.events_waits_summary_global_by_event_name WHERE NAME LIKE 'wait/io/file/innodb/%undo%';—— 查看 undo 文件 I/O 等待情况。 - 结合
INFORMATION_SCHEMA.INNODB_METRICS查询：SELECT NAME, COUNTER, COMMENT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'undo%';，例如undo_log_written（写入量）、undo_truncations（截断次数）等。
