ibdata1无法收缩是InnoDB固有设计，开启innodb_file_per_table仅使新表使用独立.ibd文件，老表数据、undo日志、数据字典等仍锁死其中；唯一缩容方式是导出、清空数据目录、初始化新实例并导入。
ibdata1 无法收缩是 InnoDB 的设计事实，不是配置没开对或操作不到位——它根本就不可逆缩容。
为什么 innodb_file_per_table=ON 后 ibdata1 还在涨
开启 innodb_file_per_table=1 只影响新表：后续建的表数据和索引写进独立 .ibd 文件，但 ibdata1 仍必须承载以下内容：
- 数据字典（
mysql库里所有系统表的元数据） - undo 日志（尤其长事务未提交时持续追加）
- 回滚段、change buffer、双写缓冲区
- 所有已存在、且从未重建过的老表的数据和索引（哪怕你删光了数据，空间也不释放）
常见错误现象：SHOW VARIABLES LIKE 'innodb_file_per_table' 返回 ON，但 ls -lh ibdata1 仍每天涨；SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE engine='InnoDB' 远小于 ibdata1 大小——说明大量历史表还锁死在里面。
ALTER TABLE ENGINE=InnoDB 真的能搬出 ibdata1 吗
能，但仅限于该表本身，且有严格前提：
- 执行前必须确认
innodb_file_per_table已生效（重启 MySQL 后查变量） - 语句实际触发表重建：
ALTER TABLE orders ENGINE=InnoDB或等效的OPTIMIZE TABLE orders - 执行后验证是否成功迁移：
SELECT FILE_NAME, TABLESPACE_NAME FROM INFORMATION_SCHEMA.FILES WHERE TABLE_NAME='orders' AND FILE_TYPE='TABLESPACE'——返回orders.ibd才算脱离共享空间 - 大表执行期间会加元数据锁（MDL），MySQL 5.6+ 虽支持 Online DDL，但若并发高、DDL 队列积压，仍可能阻塞业务
- 磁盘需预留 ≈ 原表两倍空间：先写新
.ibd，再删旧数据块
注意：mysql.innodb_table_stats 等系统表强制驻留 ibdata1，不要对它们执行此操作。
真正让 ibdata1 变小的唯一办法：重建实例
导出 → 清空数据目录 → 初始化新实例 → 导入，这是唯一能让 ibdata1 回到初始大小（如 12MB）的操作路径。原因很直接：
-
ibdata1不是日志，删了 MySQL 启动失败，报错类似InnoDB: The system tablespace must be non-empty -
OPTIMIZE TABLE、DROP TABLE、甚至mysqldump后删文件再恢复，都不影响已有ibdata1的物理尺寸 - 即使只保留 undo 分离配置（
innodb_undo_tablespaces=2+innodb_undo_log_truncate=ON），也仅能抑制未来增长，无法回收已占空间
停机窗口、备份完整性、导入耗时（尤其是百 GB 级数据）是实操中最容易被低估的硬成本。
最常被忽略的一点：就算完成重建，ibdata1 也不会是“空”的——它永远要存数据字典和系统结构，初始大小由 innodb_data_file_path = ibdata1:12M:autoextend 决定。想长期控住体积，得从第一天就开 innodb_file_per_table，并定期监控 INFORMATION_SCHEMA.INNODB_TRX 杀长事务。
