ibdata1无法缩小是innodb固有设计，唯一缩容方式是停库导出、清空数据目录、初始化新实例并导入；开启innodb_file_per_table仅使新表使用独立.ibd文件，老表需逐个执行alter table engine=innodb迁移，且必须双重验证配置生效。
查History list length是否持续增长
这是Undo Log堆积最直接的信号。只要SHOW ENGINE INNODB STATUS\G里History list length长期大于5000（尤其>10000），就说明Purge线程跟不上Undo生成速度，老版本记录卡在ibdata1里出不去。
执行命令后重点看这一段：---TRANSACTION 123456789, ACTIVE 3600 sec
如果出现类似行且sec值很大（比如几百秒以上），说明有事务挂起没提交——它会锁住对应Undo段，阻止整个Purge流程。
- 用
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5;快速揪出运行超1小时的事务 - 特别注意
TRX_STATE = 'RUNNING'但TRX_ROWS_LOCKED > 0的事务，很可能是应用层未COMMIT或连接异常中断残留 - 检查是否有
XA PREPARED状态：执行XA RECOVER;，若有输出必须手动XA COMMIT或XA ROLLBACK，否则Undo空间永远无法标记为可截断
确认innodb_undo_log_truncate是否真生效
MySQL 5.7支持自动截断Undo，但默认是关的，而且光设innodb_undo_log_truncate = ON还不够——它依赖innodb_undo_tablespaces ≥ 2，而5.7默认是0，意味着Undo全挤在ibdata1里，根本没法轮换截断。
先查当前配置：SHOW VARIABLES LIKE 'innodb_undo%';
- 若
innodb_undo_tablespaces为0，说明Undo完全绑定在ibdata1，innodb_undo_log_truncate再开也无效 - 若已设为≥2，再查
SHOW STATUS LIKE 'Innodb_undo_log_truncated';，返回值为0说明从未成功截断过，大概率是长事务或配置未重启生效 - 修改配置后必须
service mysqld restart（reload不生效），且innodb_undo_tablespaces只能在实例初始化时设置，迁移后无法动态启用
验证innodb_file_per_table是否真正开启
很多人以为开了innodb_file_per_table = 1就能缓解ibdata1膨胀，结果发现没用——因为这个参数只影响新表，老表数据仍牢牢焊死在ibdata1里，哪怕你TRUNCATE TABLE或DELETE FROM，空间也不释放。
双重验证必不可少：SELECT @@innodb_file_per_table; —— 返回1才算生效SELECT FILE_NAME, TABLESPACE_NAME FROM INFORMATION_SCHEMA.FILES WHERE TABLE_NAME = 'your_table' AND FILE_TYPE = 'TABLESPACE'; —— 若TABLESPACE_NAME是innodb_system，说明还在共享表空间
- 对大表逐个执行
ALTER TABLE `table_name` ENGINE=InnoDB;，操作后对应数据库目录下应出现table_name.ibd文件 - 该操作会锁表，百GB级表可能耗时数小时；MySQL 5.7支持部分Online DDL，但MDL锁仍可能阻塞业务写入
- 磁盘需预留≈原表大小×1.2，避免ALTER中途失败导致空间不足
为什么释放不了空间？关键点都在这里
ibdata1无法缩小是InnoDB的设计事实，不是配置错或操作漏——它根本不支持在线收缩。即使你把所有表都迁出、清空undo、kill掉全部长事务，文件体积也不会变小。
唯一缩容路径是停库→导出→删ibdata*→重初始化→导入。过程中最容易被忽略的是：
- innodb_fast_shutdown必须提前设为0，否则shutdown不干净，重启可能失败
- 导出前要确认max_allowed_packet ≥ 512M，否则大表dump会中断
- Docker环境别只删ibdata1，得清空整个datadir再重建，否则容器启动时因目录非空直接失败
