DELETE后ibd文件不缩容是正常设计行为，因InnoDB仅逻辑删除并标记空间可复用，需OPTIMIZE TABLE、ALTER TABLE或TRUNCATE等重建操作才能真正释放磁盘空间。
DELETE 后 ibd 文件不缩容是正常行为
MySQL 的 InnoDB 引擎在执行 DELETE 时，只是把行标记为“可复用”，并不真正释放磁盘空间。表数据文件（.ibd）大小几乎不会变小，这是设计使然，不是 bug 或配置错误。
常见错误现象：SELECT COUNT(*) 返回 0，但 du -h table.ibd 依然几百 MB；SHOW TABLE STATUS 显示 Data_length 没变化；磁盘使用率居高不下。
-
DELETE是逻辑删除，仅更新内部页的空闲链表和记录头标志位 - 即使加了
WHERE 1=1清空全表，也不会触发文件截断 -
OPTIMIZE TABLE或ALTER TABLE ... ENGINE=InnoDB才会重建表并释放空间，但需锁表、耗 I/O
TRUNCATE TABLE 能释放空间但有严格限制
TRUNCATE TABLE 本质是删掉原表文件、新建空表，所以 .ibd 立刻变小。但它不是万能解法，得看你的场景是否允许。
使用场景：确定要清空整张表，且不需要事务回滚、不依赖外键级联、无活跃触发器依赖该表。
- 不能在有外键引用的子表上直接
TRUNCATE（会报错ERROR 1701 (HY000)） - 不走 binlog row 格式事件，主从复制中可能跳过某些审计逻辑
- 无法带
WHERE条件——它只能整表清空 - 在 MySQL 8.0+ 中，如果启用了
innodb_file_per_table=OFF，TRUNCATE仍不会缩容系统表空间（ibdata1）
真正释放 ibd 空间必须重建表
只有让 InnoDB 把数据重新写入新页、丢弃旧页，才能让文件系统回收空间。核心操作就是“重建”——但方式不止一种，选错代价很大。
-
OPTIMIZE TABLE t：最常用，但会锁表（5.7 及以前是全表锁；8.0 支持 online DDL，但仍需短暂排他锁） -
ALTER TABLE t ENGINE=InnoDB：效果等同OPTIMIZE，语义更明确，推荐用于脚本化操作 -
mysqldump+DROP+CREATE+INSERT：适合大表分批导出，但停机时间长、容易丢数据（如中间 binlog 未同步） - 不要用
innodb_file_per_table=OFF下的ALTER——它只会让空间留在共享表空间里，.ibd不存在，自然不缩
预防后续 ibd 膨胀失控的关键配置
光解决一次不够，高频写入+频繁删除的业务，很容易反复陷入空间不释放的循环。关键不是“怎么删”，而是“怎么让删完的空间能被复用”。
- 确认
innodb_file_per_table=ON（默认开启，但老实例可能关着）——这是.ibd独立存在的前提 - 避免长期运行大事务：未提交的事务会阻止 purge 线程清理已删记录，导致空间卡住
- 监控
INFORMATION_SCHEMA.INNODB_METRICS中的dml_deleted和purg_trx_released，判断 purge 是否滞后 - 对超大表，考虑分区（
PARTITION BY RANGE），用DROP PARTITION实现秒级空间回收，比DELETE+OPTIMIZE高效得多
真正难的不是执行哪条命令，而是判断当前表能不能安全重建、purge 线程有没有被堵住、以及下次删数据前要不要先调低 innodb_purge_batch_size。这些细节不查 SHOW ENGINE INNODB STATUS 和 information_schema 表，光看 .ibd 大小永远找不到根因。
