ALTER TABLE ENGINE=InnoDB后.ibd文件变大，是因InnoDB将数据、索引、事务元数据整合存储且默认填充因子高，叠加原MyISAM碎片、长字段、FULLTEXT索引及未启用innodb_file_per_table等导致空间膨胀。
ALTER TABLE ENGINE=InnoDB 后表空间暴增，不是转换失败，而是 MyISAM → InnoDB 的物理存储结构差异放大了原有碎片或配置缺失；直接删文件或硬重启会丢数据，必须结合引擎特性与空间管理逻辑来处理。
为什么 ALTER TABLE ENGINE=InnoDB 后 .ibd 文件变大？
MyISAM 表由 .MYD（数据）+ .MYI（索引）分离存储，.MYD 大小≈实际数据体积；而 InnoDB 将数据+主键+二级索引+事务元数据打包进单个 .ibd 文件，且默认填充因子、页预留、聚簇索引结构都会导致体积膨胀。尤其当原 MyISAM 表存在大量删除/更新空洞，或字段含 VARCHAR(2000)、TEXT 等长列时，InnoDB 重建过程会分配更多页并固化冗余空间。
- 未启用
innodb_file_per_table=1时，转换后数据仍写入共享表空间ibdata1，该文件永不缩容 —— 此时你根本看不到.ibd，但磁盘占用已不可逆增长 - 原表有
FULLTEXT索引：MyISAM 允许，InnoDB 要求额外存储结构，ALTER过程中可能隐式扩容 - 转换时未指定
ROW_FORMAT=COMPRESSED或KEY_BLOCK_SIZE，默认用DYNAMIC格式，对大字段更“奢侈”
确认是否真在独立表空间里
别凭 SHOW CREATE TABLE 判断 —— 它不显示 FILE_PER_TABLE 状态。真正要看的是：
-
SELECT @@innodb_file_per_table;—— 必须为1，否则所有新表都进ibdata1 -
SELECT TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 't';—— 输出中需明确含ROW_FORMAT或FILE_PER_TABLE字样 -
ls -lh /var/lib/mysql/db_name/t.ibd—— 存在且大小异常，说明已走独立空间；若只有ibdata1变大，问题根源在共享表空间模式
暴增后怎么安全收缩 .ibd 文件？
不能删文件，不能跳过重建步骤。关键动作链必须完整：
- 先确保
innodb_file_per_table=1已生效（查变量+查表选项），否则OPTIMIZE无效 - 执行
ALTER TABLE t ENGINE=InnoDB;或OPTIMIZE TABLE t;—— 二者等效，但前者语义更直白，避免某些版本对OPTIMIZE的歧义解析 - 大表（>5GB）务必加
SET SESSION innodb_tmpdir = '/bigdisk/tmp';，防止重建过程把/tmp写爆 - 锁表时间敏感的场景，改用
pt-online-schema-change --alter "ENGINE=InnoDB" --execute，它通过影子表+触发器规避长锁
注意：TRUNCATE TABLE t 后 .ibd 大小不变是正常行为 —— 它只清空页，不重分配文件；收缩必须跟重建操作。
哪些操作会白忙活？
常见无效尝试：
- 直接
rm t.ibd再启动 MySQL —— 报错Table doesn't exist或崩溃，因为 InnoDB 元数据还在ibdata1或数据字典里 - 只调
innodb_temp_data_file_path却不设innodb_fast_shutdown=0+ 完整重启 ——ibtmp1不清理，旧临时段残留，新限制不生效 - 对仍在
ibdata1中的老表跑OPTIMIZE—— 仅整理内部页，ibdata1文件大小纹丝不动 - 用
mysqldump导出再导入来“重置” —— 若导出前没关innodb_file_per_table，导入后还是挤进ibdata1，空间问题照旧
真正要盯住的，从来不是单条命令，而是表空间归属路径 + 重建触发时机 + 临时空间承载能力这三点。漏掉任一环，.ibd 就会继续躺在磁盘上，安静地膨胀。
