启用innodb_file_per_table=1后ibdata1仍膨胀，因其继续存储系统表、undo日志、回滚段等；真正缩小需导出、初始化新实例、再导入。
ibdata1 文件不会因启用 innodb_file_per_table=1 而变小，迁移后它仍会持续膨胀——这不是配置没生效，而是你没动到真正写入它的那部分数据。
为什么开了 innodb_file_per_table 还在涨？
该参数只影响新创建的表：它们的数据和索引会落到独立的 .ibd 文件里。但 ibdata1 本身仍承载系统级职责，包括：
- 数据字典（
mysql库下所有系统表） - undo 日志段（
mysql/innodb_undo_*） - 回滚段、change buffer、doublewrite buffer
- 所有存量 InnoDB 表的历史数据（哪怕你删过表，空间也不释放）
迁移后若未重建存量表，这些老数据仍在 ibdata1 中；同时 undo 日志持续写入，尤其存在长事务时，ibdata1 就会“默默长大”。
如何确认哪些东西还在往 ibdata1 写？
先查当前 undo 表空间是否已分离：
SELECT NAME, FILE_SIZE FROM information_schema.INNODB_SYS_TABLESPACES WHERE NAME LIKE 'mysql/innodb_undo_%';
若返回空，说明 undo 还在 ibdata1 里——这是膨胀主因之一。再查是否有卡住的事务：
SELECT TRX_ID, TRX_STARTED, TRX_STATE, TRX_QUERY FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5;
如果 TRX_STARTED 是几小时甚至几天前的时间，且 TRX_STATE = RUNNING，这就是 undo 堆积的直接证据。
不重建实例的前提下，能压住增长吗？
可以，但只能“堵”，不能“缩”。重点控制 undo 和 purge 行为：
- 确保
innodb_undo_log_truncate = ON（MySQL 5.7+），并设innodb_max_undo_log_size = 1073741824（1G） - 配
innodb_undo_tablespaces = 2（需重启，且必须在初始化时设置，迁移后无法动态启用） - 调大
innodb_purge_threads = 4（默认是 1），加快旧 undo 清理 - 禁止应用层长期持有事务：检查 ORM 是否默认
autocommit=0，SQL 执行完必须显式COMMIT或ROLLBACK - 避免单次大事务：比如批量更新超 10 万行，拆成每 5000 行
COMMIT一次
注意：innodb_undo_tablespaces 必须在实例初始化阶段启用，迁移后的运行中实例无法开启——这点极易被忽略。
真正缩小 ibdata1 的唯一路径
导出 → 初始化新实例 → 导入。关键点不是“删文件”，而是“重置共享表空间结构”：
- 停库后用
mysqldump --all-databases --single-transaction导出（避免锁表） - 备份原
datadir后彻底清空（含ibdata1、ib_logfile*、mysql.sock等） - 用
mysqld --initialize --datadir=...初始化，此时生成的ibdata1只有 12MB - 启动后立即执行
SET GLOBAL innodb_file_per_table = ON;（虽配置文件已设，但确保 session 级也生效） - 导入数据：每个表都会生成独立
.ibd，ibdata1不再接收新表数据
复杂点在于：迁移后若已有大量业务表，又没做逻辑备份，就只能靠逐表 ALTER TABLE t ENGINE=InnoDB 搬迁——但该操作不减少 ibdata1 体积，只防止它继续吃新数据；而 undo 和系统元数据仍锁死其中，无法释放。
