ibdata1文件无法自动收缩，即使删除所有表仍保持原大小，因其作为InnoDB共享表空间存储数据字典、undo日志、回滚段等关键元数据；开启innodb_file_per_table仅使新表使用独立.ibd文件，存量表需逐个执行ALTER TABLE ... ENGINE=InnoDB才能迁移出ibdata1；直接删除ibdata1将导致MySQL启动失败。
ibdata1 文件不会自动收缩，哪怕你删光了所有表，它也还是那么大——这是 InnoDB 共享表空间的固有行为。开启 innodb_file_per_table 只能控制新创建的表走独立表空间，对已存在的、数据还在 ibdata1 里的表完全无效。
innodb_file_per_table=1 开启后，老表数据还在 ibdata1 里
- 新建的表会生成单独的
.ibd文件，数据和索引不再写入ibdata1 - 但所有已有表（尤其是历史积累的大表）的数据、索引、undo、change buffer 等仍锁死在
ibdata1中 -
ibdata1的大小只增不减，OPTIMIZE TABLE 或 ALTER TABLE ENGINE=InnoDB 对它毫无影响
常见错误现象：
- 配置改了、MySQL 重启了、
SHOW VARIABLES LIKE 'innodb_file_per_table'返回ON，但ibdata1还是每天涨 -
ls -lh看到ibdata1占用 50G，而所有.ibd加起来才 5G，说明绝大部分数据仍在共享空间
所以：
- ✅ 开启
innodb_file_per_table是必要前提 - ❌ 它本身不是“解决”方案，只是为后续清理铺路
如何真正把数据从 ibdata1 搬出来
必须对每个存量表显式重建，让 InnoDB 把它的数据从共享空间挪到独立 .ibd 文件中：
- 执行
ALTER TABLE table_name ENGINE=InnoDB - 或更稳妥的
OPTIMIZE TABLE table_name（等价于上一条，但带统计更新）
注意点：
- 表越大，执行时间越长，期间该表会被锁（MySQL 5.6+ 支持 Online DDL，但仍有元数据锁等待风险）
- 必须确保磁盘有足够空间：重建时先写新
.ibd，再删旧数据，峰值占用 ≈ 原表大小 × 2 - 不建议对系统表（如
mysql.innodb_table_stats）执行此操作；它们强制驻留ibdata1 - 执行前确认
innodb_file_per_table已生效，否则重建完还是回写进ibdata1
示例：
ALTER TABLE orders ENGINE=InnoDB;执行后检查：
SELECT FILE_NAME, TABLESPACE_NAME FROM INFORMATION_SCHEMA.FILES WHERE TABLE_NAME = 'orders' AND FILE_TYPE = 'TABLESPACE';若返回
orders.ibd 而非 innodb_system，说明已成功脱离共享空间。
为什么不能直接删 ibdata1？
因为 ibdata1 不只是“存数据的文件”，它还硬编码着：
- 数据字典（所有表结构定义）
- 回滚段（
ROLLBACK依赖） - undo 日志（MVCC 和事务回滚基础）
- change buffer（缓冲区合并逻辑）
- 双写缓冲区（崩溃恢复关键）
直接删掉 → MySQL 启动失败，报错类似：
InnoDB: The system tablespace must be writable
或Cannot open table mysql/innodb_table_stats
你看到的“删 ibdata1 + 重导数据”方案，本质是彻底重建整个实例：
- 停服 → 清空所有数据文件 → 改配置 → 启动空实例 → 用
mysqldump导入 - 这期间所有表都变成新对象，自然走独立表空间
- 但它不是“缩容”，而是“换血”，业务中断不可避免
ibdata1 的膨胀是累积性的，一旦它承载过大量历史事务、长事务、未 purge 的 undo，就很难靠在线操作回退。最务实的做法是：现在就开启 innodb_file_per_table，再逐个迁移核心大表；别等它涨到上百 GB 再动手——那时磁盘、时间、锁等待成本都会陡增。
