innodb的delete仅逻辑标记删除，不释放磁盘空间；必须通过optimize table或alter table engine=innodb重建表才能真正释放.ibd文件空间。
DELETE 不释放表空间，是 InnoDB 的正常行为，不是误操作、配置错误或 bug——它压根就不会把数据页还给操作系统。
为什么 DELETE 后 du -sh table.ibd 完全不变
InnoDB 的 DELETE 只是把行头的 delete_mask 位设为 1，并更新页内空闲链表。整块数据页仍保留在 .ibd 文件里，供后续 INSERT 复用。
这意味着：
- Data_length 和 INDEX_LENGTH 基本不降（它们统计的是“有效数据页”，不是文件大小）
- Data_free 反而可能变大（表示“可复用但未归还 OS”的页变多了）
- 即使 SELECT COUNT(*) = 0，.ibd 文件尺寸也纹丝不动
这不是空间泄漏，而是为 MVCC、并发写入和避免频繁文件截断做的权衡。
OPTIMIZE TABLE 和 ALTER TABLE ... ENGINE=InnoDB 到底做了什么
两者在 InnoDB 表上效果一致：重建聚簇索引。本质是：
- 新建一个空的 .ibd 文件，按主键顺序重排所有未被标记删除的行
- 拷贝过程中自然合并 B+ 树节点、收缩索引页、丢弃空页
- 完成后原子替换原表，旧文件由操作系统回收
注意：
- MySQL 5.7+ 中
OPTIMIZE TABLE t等价于ALTER TABLE t FORCE，默认走ALGORITHM=INPLACE（仍有锁） - 它不写 binlog（ROW 格式下），主从
.ibd大小会不一致 - 不是“整理碎片”，是物理重建；没重建，
Data_free高也没用
执行前必须检查的三件事，缺一不可
- 查磁盘余量：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，否则 purge 卡住，重建也清不干净
- 确认基础条件：SHOW VARIABLES LIKE 'innodb_file_per_table' 必须为 ON；SHOW CREATE TABLE t\G 中必须含 ENGINE=InnoDB什么情况下不该直接跑 OPTIMIZE TABLE
- 表 >100GB 或磁盘使用率 >85%，临时文件极易写满，中途失败后残留临时表更难清理
- 业务不能停写：它加 MDL 锁，DML 会被阻塞，连接池可能耗尽
- 只删部分历史数据（如只保留最近 6 个月）：优先用 mysqldump --where="create_time > '2025-01-01'" db t > t_recent.sql 导出再重建
- 已用分区表：直接 DROP PARTITION p2023_q1，秒级释放，不锁全表
真正容易被忽略的是：Data_free 高 ≠ 必须优化——它本就是为写入性能预留的缓冲空间；重建的关键，从来不是“碎片数字”，而是你是否真需要把空间还给操作系统，以及能否承受重建过程中的 I/O 压力和锁开销。
