MySQL执行DELETE后磁盘空间不释放是InnoDB主动设计，仅逻辑标记删除、不归还页给OS；必须通过OPTIMIZE TABLE或ALTER TABLE ENGINE=InnoDB重建表才能真正释放空间。
MySQL执行DELETE后磁盘空间不释放，不是故障、不是配置错、也不是SQL没生效——这是InnoDB引擎的主动设计，它压根就不打算把页还给操作系统。
DELETE只是标记删除，不碰物理文件
InnoDB的DELETE操作本质是逻辑删除：仅将行头的delete_mask位设为1，并更新该页内的空闲链表。整块16KB的数据页仍保留在.ibd文件中，供后续INSERT复用。
-
du -sh table.ibd输出完全不变 -
SHOW TABLE STATUS LIKE 't'\G中的Data_length几乎不降，哪怕COUNT(*) = 0 -
Data_free值反而可能增大——它代表“可复用但未归还OS”的页数，不是已释放空间 - 事务未提交本身不导致空间不释放，但长事务会阻塞
purge线程，让已删行长期滞留
真正释放空间必须重建表
只有物理重建才能让操作系统回收磁盘空间，核心手段就两个：OPTIMIZE TABLE t和ALTER TABLE t ENGINE=InnoDB。它们在InnoDB表上效果一致，都是：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 新建一个空
.ibd文件，按当前索引结构重排聚簇索引 - 逐行扫描原表，只拷贝未被标记删除的有效行
- 拷贝完成后原子性地
DROP原表、RENAME新表 - 旧文件由OS真正回收（注意：不走binlog，主从
.ibd大小会不一致）
执行前不检查这三件事，大概率失败
盲目执行OPTIMIZE TABLE或ALTER TABLE t ENGINE=InnoDB极易写满磁盘、锁死业务或中途报错。
- 查磁盘余量：
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
什么情况下不该直接重建表
重建不是万能解药，尤其对活跃大表，风险常高于收益。
- 表 >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压力和锁开销
最常被忽略的一点：即使你确认了所有前提并成功执行了OPTIMIZE TABLE，如果表本身刚建完就删光、或者数据本来就非常紧凑，.ibd文件大小也可能纹丝不动——因为根本没多少空洞可压缩。
