delete后.ibd文件大小不变是innodb正常设计行为，因其仅逻辑标记删除行、不物理回收页空间；必须通过optimize table或alter table engine=innodb重建表才能真正释放磁盘空间。
DELETE 后 .ibd 文件大小不变，不是 MySQL 没干活，也不是磁盘坏了——这是 InnoDB 引擎的默认行为，删的是“逻辑可见性”，不是物理块。
为什么 DELETE 不缩 .ibd 文件
InnoDB 的 DELETE 只是把行头的 delete_mask 位设为 1，并更新页内空闲链表；整页（Page）仍保留在文件里，供后续 INSERT 复用。所以：
-
du -sh table.ibd、SHOW TABLE STATUS中的Data_length完全不会变小 - 哪怕
SELECT COUNT(*) = 0，只要没重建表，文件尺寸纹丝不动 -
Data_free值反而可能变大——它表示“当前可复用但尚未归还 OS 的页数”，不是泄漏，是预留缓冲 - 若
innodb_file_per_table = OFF，所有表共用ibdata1，删再多也永远不缩
OPTIMIZE TABLE 和 ALTER TABLE ENGINE=InnoDB 实际做了什么
两者在 InnoDB 表上效果一致：新建空表 → 逐行拷贝有效数据 → 替换原 .ibd 文件。本质是物理重建，旧页被丢弃，OS 层面才真正回收空间。
- 全程加
MDL_EXCLUSIVE锁（MySQL 5.7+ 中OPTIMIZE TABLE等价于ALTER TABLE ... FORCE），DML 被阻塞，SELECT性能明显抖动 - 需要额外磁盘空间 ≥ 当前表的
Data_length（临时表阶段写满直接报ERROR 1034） - 不走 binlog（ROW 格式下），主从
.ibd大小会不一致；RDS 等托管服务可能禁用或转为只读副本执行
执行前必须验证的三件事
跳过任意一项，就可能锁死业务、写满磁盘或中途失败。
- 查磁盘余量：
df -h /var/lib/mysql，确认剩余空间 ≥SHOW TABLE STATUS LIKE 't'\G中的Data_length（建议留 1.5 倍冗余） - 查长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 600，有结果就得先KILL - 确认引擎和独立表空间：
SHOW CREATE TABLE t\G输出中必须含ENGINE=InnoDB，且实例级参数innodb_file_per_table = ON
什么情况下不该直接跑 OPTIMIZE TABLE
盲目重建活跃大表，比不优化更伤。
- 表 >100GB 或磁盘使用率 >85% 时，风险极高：临时文件极易写满，锁表时间不可控
- 只删部分数据？用
mysqldump --where="create_time > '2025-01-01'" db t > t_recent.sql导出再重建导入 - 整表清空且允许停机？优先用
TRUNCATE TABLE t——它删文件再建新.ibd，立刻释放空间（但不支持WHERE，外键子表上会报ERROR 1701）
真正容易被忽略的是：Data_free 高 ≠ 必须优化——它本就是为写入性能预留的缓冲空间；重建表的关键，从来不是“碎片多不多”，而是“是否真需要立刻释放磁盘”以及“能否承受重建过程中的 I/O 和锁开销”。
