delete后磁盘空间不释放是innodb正常设计，因仅逻辑标记删除行而不物理回收，需optimize table或alter table engine=innodb重建表才能真正缩容.ibd文件。
DELETE 后磁盘空间不释放是 InnoDB 的正常行为
不是 bug，也不是配置错误，而是 InnoDB 引擎的设计使然。DELETE 操作本质是“标记删除”：只把数据行的 delete_mask 位设为 1，并不立即擦除物理页内容，也不收缩 .ibd 文件。被删的数据页仍保留在表空间中，等待后续 INSERT 复用——这是为了兼顾 MVCC、并发写入和性能稳定性。
常见误判场景包括：
- 执行
DELETE FROM t WHERE ...后立刻du -sh t.ibd，发现文件大小几乎不变 - 监控显示磁盘使用率没降，误以为 SQL 没生效或有残留事务
- 在 RDS 上删完库（
DROP DATABASE）但云盘空间未释放，怀疑权限或后台进程卡住
事务未提交本身不会导致空间不释放，但长事务会阻塞 purge 线程
InnoDB 的空间回收依赖后台的 purge 线程，它负责真正清理被标记删除的记录和页。但如果存在长时间未提交的事务（比如一个开了 2 小时还没 COMMIT 或 ROLLBACK 的事务），purge 就不敢动那些可能被该事务快照引用的旧版本数据——结果就是：已删行长期滞留，Data_free 值持续偏高，碎片越积越多。
可快速验证是否存在这类问题：
- 查活跃事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 600; - 看 purge 进度：
SHOW ENGINE INNODB STATUS\G，搜索Purge done for trx's n:o ，对比当前最大事务号 - 检查
Data_free是否异常高：SHOW TABLE STATUS LIKE 't'\G，若值远大于Data_length的 10%，说明碎片严重
OPTIMIZE TABLE 和 ALTER TABLE ENGINE=INNODB 都会重建表，但风险不同
两者都能真正释放空间，原理都是新建空表、逐行拷贝有效数据、替换原表文件。但它们对线上服务的影响有明显差异：
-
OPTIMIZE TABLE t：在 MySQL 5.7+ 对 InnoDB 表等价于ALTER TABLE t FORCE；会全程加S（共享）元数据锁，期间禁止 DDL，但允许 DML（不过性能下降明显） -
ALTER TABLE t ENGINE=INNODB：同样重建，但某些旧版本 MySQL 可能触发更激进的锁策略；RDS 等托管服务常将其封装为“在线 DDL”，但仍需注意ALGORITHM=INPLACE是否生效 - 两个命令都会短暂获取
MDL锁两次（开始前 + 结束后），若此时恰有慢查询或大事务正在执行，容易卡住整个ALTER流程 - 操作前务必确认磁盘剩余空间 ≥ 当前表
Data_length的 1.5 倍，否则可能因临时文件写满而失败
真正释放空间的关键是让 ibd 文件变小，而不是只清空 data_free
Data_free 字段只是 InnoDB 内部估算的“可用但未分配给行”的空间量，它不等于操作系统可见的磁盘释放量。只有当 .ibd 文件实际缩小，du 或云平台监控才会有变化。而这一点，仅靠 DELETE 或 TRUNCATE 都做不到——TRUNCATE 虽快，但仍是逻辑清空，InnoDB 默认仍保留原文件尺寸（除非启用了 innodb_file_per_table=ON 且配合 innodb_file_format=Barracuda 等条件）。
所以别被 Data_free 数值迷惑。要确认是否真释放了磁盘，必须：
- 执行重建命令后，用
ls -lh table_name.ibd对比文件大小 - 在 RDS 控制台或
df -h查宿主机磁盘使用率变化 - 注意：如果表使用系统表空间（
ibdata1），即使重建单表也无法缩小ibdata1，只能迁移整库
