InnoDB的DELETE仅逻辑标记删除，不释放磁盘空间；必须通过OPTIMIZE TABLE或ALTER TABLE ENGINE=InnoDB重建表才能真正释放.ibd文件空间。
DELETE 不释放磁盘空间是 InnoDB 的正常行为，不是删错了、没生效，也不是配置漏了——它压根就不会把页还给操作系统。
为什么 DELETE 后 du -sh table.ibd 完全不变
InnoDB 的 DELETE 是逻辑删除：只把行头的 delete_mask 位设为 1，并更新页内空闲链表。整页仍保留在 .ibd 文件中，供后续 INSERT 复用。
-
Data_length不降：它统计的是“有效数据页”大小，已删行不计入，但页本身没丢 -
Data_free反而可能变大：代表“可复用但未归还 OS”的页数，不是已释放空间 - 即使
SELECT COUNT(*) = 0，文件尺寸也纹丝不动——这不是泄漏，是设计权衡
OPTIMIZE TABLE 和 ALTER TABLE t ENGINE=InnoDB 到底在干什么
两者在 InnoDB 表上效果一致：重建表。本质是原子三步：
- 新建一个空
.ibd，按当前索引结构重排聚簇索引 - 逐行扫描原表，只拷贝未被标记删除的有效行
- 原子性
DROP原表、RENAME新表，OS 回收旧文件
注意：OPTIMIZE TABLE t 在 MySQL 5.7+ 等价于 ALTER TABLE t FORCE，默认走 ALGORITHM=INPLACE（仍需锁），但全程不写 binlog（ROW 格式下主从 .ibd 大小会不一致）。
执行前不检查这三件事，大概率卡死或写满磁盘
盲目执行等于主动触发事故：
- 查磁盘余量：
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 高 ≠ 必须优化——它本就是为写入性能预留的缓冲空间；重建的关键，从来不是“碎片数字”，而是你是否真需要把空间还给操作系统，以及能否承受重建过程中的 I/O 压力和锁开销。
