DELETE后表空间未释放是InnoDB正常行为，因其仅逻辑标记删除行、不物理回收页空间；必须通过OPTIMIZE TABLE或ALTER TABLE ENGINE=InnoDB重建表才能真正释放磁盘空间。
DELETE后表空间没释放？先确认存储引擎类型
MySQL里DELETE只是标记行删除，不自动回收磁盘空间——这在InnoDB中尤其明显。而MyISAM会立刻释放，但已基本淘汰。你遇到的“删完还占着”大概率是InnoDB表，它用的是逻辑删除+后台purge机制，不是删完就缩。
TRUNCATE TABLE能立刻释放空间，但有硬限制
TRUNCATE TABLE会重建表结构、重置AUTO_INCREMENT、释放全部空间，比DELETE快得多也干净得多。但它不能带WHERE条件，也不能触发DELETE触发器，事务中执行还会隐式提交——如果你要删部分数据（比如只删一年前日志），这条路走不通。
- 适用场景：
TRUNCATE TABLE t_log→ 全表清空且无条件依赖 - 风险点：执行后无法回滚，
FOREIGN KEY约束存在时可能报错ERROR 1701 (HY000) - 注意：
TRUNCATE不走undo log，所以不会被binlog按行记录（ROW格式下），主从延迟或闪回时需额外留意
真正释放InnoDB空间：OPTIMIZE TABLE或ALTER TABLE重建
对已DELETE大量数据的InnoDB表，必须显式重建才能收缩.ibd文件。推荐优先用ALTER TABLE ... ENGINE=InnoDB，它比OPTIMIZE TABLE更可控（后者在某些版本会加全局锁）。
-
ALTER TABLE t_log ENGINE=InnoDB→ 触发重建，释放碎片空间，同时更新统计信息 - 操作期间表可读不可写（MDL写锁），线上大表务必选低峰期，预估时间：100GB表通常需10–30分钟
- 如果启用了
innodb_file_per_table=OFF，空间根本不会返还给文件系统——必须先改配置+重启+重建所有表才生效 - SSD上不建议频繁做，重建会产生大量I/O和临时空间（需预留2倍原表大小磁盘）
避免反复踩坑：日常该怎么做
别等表涨到500GB才想起来清理。真正省事的做法是设计阶段就规避：
- 按时间分区：
PARTITION BY RANGE (created_at)，删旧数据直接DROP PARTITION，秒级释放空间 - 归档冷数据到历史表后再
TRUNCATE，比原表DELETE安全又快 - 监控
data_free字段：SELECT table_name, data_length, data_free FROM information_schema.tables WHERE table_schema='db'，data_free持续>20%说明该优化了 - 不要用
DELETE FROM t WHERE id 这种扫全表的语句——加<code>LIMIT分批删，否则undolog爆炸、锁升级、主从延迟飙升
空间回收不是删完就结束的事，而是从建表、分区、清理策略到监控的一整条链路。最常被忽略的是innodb_file_per_table开关状态和分区设计，这两项没设对，后面所有OPTIMIZE都白忙。
