delete后磁盘空间不释放是innodb正常行为，因其仅逻辑标记删除行、不物理回收页空间；必须通过optimize table或alter table engine=innodb重建表才能真正释放.ibd文件空间。
DELETE 后磁盘空间没释放，不是操作失败，也不是配置错误，是 InnoDB 引擎的默认行为——它根本就不会把页还给操作系统。
DELETE 只是标记删除，不碰物理文件
InnoDB 的 DELETE 本质是把行头的 delete_mask 位设为 1，并更新页内空闲链表。数据还在 .ibd 文件里，只是对新查询不可见。
-
du -sh table.ibd、SHOW TABLE STATUS中的Data_length完全不会变小 - 即使
SELECT COUNT(*) = 0，文件尺寸也纹丝不动 -
Data_free值反而可能变大——这不是泄漏，是引擎预留的“待复用页”缓冲区
真正释放空间必须重建表
只有让 InnoDB 把有效数据重写进新页、丢弃旧页，文件系统才能回收空间。可用的命令只有两个：
-
OPTIMIZE TABLE t：MySQL 5.7+ 对 InnoDB 等价于ALTER TABLE t FORCE，会加 MDL_EXCLUSIVE 锁，DML 被阻塞 -
ALTER TABLE t ENGINE=InnoDB：原理相同，但某些旧版本或 RDS 环境可能退化为 copy 算法，锁表时间更长
两者都不走 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 高 ≠ 必须优化——它本就是为写入性能预留的缓冲空间；重建表的关键，从来不是碎片数字，而是你是否真的需要 OS 层面的空间回收。
