答案是innodb的delete仅逻辑标记删除，不物理回收空间；必须通过optimize table或alter table engine=innodb重建表才能真正释放.ibd文件空间。delete只设delete_mask位并更新空闲链表，页仍保留在文件中供复用，故du -sh和data_length不变；optimize table本质是重建表、重写有效数据、丢弃旧页，使os回收空间，但需满足innodb_file_per_table=on、无长事务、磁盘冗余≥1.2倍等前提。
DELETE大量数据后磁盘空间不释放，不是操作失败，也不是配置错误，是InnoDB引擎的默认行为——它根本不会把页还给操作系统。
为什么DELETE不缩.ibd文件大小
InnoDB的DELETE本质是逻辑标记：只把行头的delete_mask位设为1，并更新页内空闲链表。整页仍保留在.ibd文件中，供后续INSERT复用。
-
du -sh table.ibd输出完全不变 -
SHOW TABLE STATUS里的Data_length几乎不降 - 即使
SELECT COUNT(*) = 0，文件尺寸也纹丝不动 -
Data_free值反而可能变大——这不是泄漏，是引擎预留的“待复用页”缓冲区
OPTIMIZE TABLE到底做了什么
它不是“整理碎片”的魔法命令，而是触发一次完整重建：CREATE TABLE new AS SELECT * FROM old + DROP old + RENAME new → old。所有有效数据重写进新页，旧页丢弃，OS层面才真正归还空间。
- 等价于
ALTER TABLE t ENGINE=InnoDB，两者效果一致 - 必须满足
innodb_file_per_table = ON，否则重建无效（数据锁在共享表空间ibdata1里） - 操作前需确保剩余磁盘空间 ≥ 当前
.ibd大小 × 1.2，否则中途失败会残留临时表 - 全程加MDL锁，高峰期容易卡住，尤其遇到
SELECT ... FOR UPDATE或慢查询时
哪些情况不该直接跑OPTIMIZE TABLE
盲目重建大表，风险远高于收益。
- 表 > 50GB 且磁盘使用率 > 85%：临时文件极易写满，操作中断后更难清理
- 业务不能停写：锁表期间DML被阻塞，连接池耗尽很常见
- 数据只是阶段性归档（如只保留最近6个月）：更适合导出再重建
- 从库上直接执行：它不走binlog，主从
.ibd大小会不一致
真正释放空间的关键不在删，而在重建；而重建的前提，是确认innodb_file_per_table开着、没长事务堵着purge、磁盘还有足够余量——这三个条件缺一不可。最容易被忽略的是Data_free值高 ≠ 文件一定能缩，如果表本身刚建完就删光，OPTIMIZE后.ibd可能也不变小。
