oracle中查询当前undo表空间状态最可靠方式是查数据字典dba_tablespaces和v$parameter，而非mysql的innodb_tablespaces（该视图属mysql，不适用于oracle）；oracle需用select * from dba_tablespaces where contents = 'undo'确认undo表空间及其状态，结合show parameter undo_tablespace查看当前生效实例。
怎么查当前Undo表空间状态
直接查数据字典最可靠：SELECT * FROM information_schema.INNODB_TABLESPACES WHERE SPACE_TYPE = 'Undo'。它能列出所有undo表空间名称、路径、状态（ACTIVE或INACTIVE）、文件大小和是否加密。
别依赖SHOW VARIABLES LIKE '%undo%'——它只显示配置项，不反映实际存在的表空间；比如innodb_undo_tablespaces在8.0.21+版本里永远是2，哪怕你用SQL建了5个，这个值也不会变。
常见误判点：
- 看到
innodb_undo_log_truncate = ON就以为“正在收缩”，其实只是允许触发条件成立；得配合innodb_max_undo_log_size和purge进度才真正生效 - 监控
DATA_FREE字段没意义：undo表空间的DATA_FREE始终为0，它的空间回收靠truncate，不是传统碎片整理
哪些指标能暴露Undo空间压力
重点盯三个Performance Schema视图：
-
performance_schema.events_statements_summary_by_digest：找CREATE UNDO TABLESPACE或DROP UNDO TABLESPACE执行频次突增，说明应用层在频繁手动管理，可能配置不合理 -
information_schema.INNODB_METRICS中过滤name LIKE 'undo%'，关注undo_truncations（实际触发截断次数）和undo_logs_added（新日志段分配数） -
information_schema.INNODB_TRX里看trx_started时间过长的事务——长时间运行的事务会阻止purge线程清理旧undo，导致undo文件持续增长
特别注意：Innodb_undo_log_pages状态变量已废弃，MySQL 8.0.23起不再更新，别再用它做判断依据。
调优关键参数怎么设才有效
以下参数在8.0中仍有效，但作用范围和旧版不同：
-
innodb_undo_directory：仅影响初始化时创建的undo_001.ibu和undo_002.ibu位置；后续用CREATE UNDO TABLESPACE建的必须写绝对路径，且该路径需在innodb_directories列表中 -
innodb_max_undo_log_size：默认1073741824（1G），建议调到2147483648（2G）以上；太小会导致频繁truncate，增加I/O抖动；太大则可能撑满磁盘，尤其当有长事务阻塞purge时 -
innodb_purge_rseg_truncate_frequency：默认128，即每128次purge操作检查一次回滚段是否可释放；高并发短事务场景可降到32，加快空间回收；但别设成1，否则purge线程开销过大
禁用innodb_undo_log_truncate等于放弃自动空间管理，除非你有外部脚本定期人工DROP，否则极易磁盘告警。
为什么删了undo表空间磁盘空间没立刻释放
执行DROP UNDO TABLESPACE undo_003后，文件不会立即从磁盘删除，而是进入“延迟删除”状态，由后台purge线程异步清理。这是InnoDB的设计机制，避免大文件删除阻塞主线程。
验证是否真在清理：
- 查
information_schema.INNODB_TABLESPACES，状态应为DROPPING - 观察
innodb_purge_truncate_count状态变量是否递增 - 用
lsof -p $(pidof mysqld) | grep undo确认文件句柄是否还被持有
最容易忽略的一点：如果实例启用了innodb_undo_log_encrypt = ON，删除过程会更慢——加密密钥解绑和块擦除需要额外CPU周期，且无法跳过。
