delete后磁盘空间不释放是innodb正常行为，因其仅逻辑标记删除行、不物理回收页空间；必须通过optimize table或alter table engine=innodb重建表才能真正缩容.ibd文件。
DELETE 后磁盘空间不释放，不是 bug，也不是配置错了——这是 InnoDB 的默认行为。它只做逻辑删除，不归还页给操作系统，.ibd 文件大小纹丝不动是完全正常的。
为什么 DELETE 不缩 .ibd 文件？
InnoDB 的数据以页（16KB）为单位存储。DELETE 实际只是把行头的 delete_mask 位设为 1，并更新页内空闲链表，页本身仍保留在文件里。后续 INSERT 可复用这些“空洞”，所以：
- du -sh table.ibd 不变
- SHOW TABLE STATUS 中的 Data_length 不降
- 即使 SELECT COUNT(*) = 0，文件尺寸照样不变
- Data_free 值反而可能变大——它表示“标记可复用但尚未归还 OS”的空间总量，不是泄漏，是设计如此
OPTIMIZE TABLE 和 ALTER TABLE ENGINE=InnoDB 怎么选？
两者在 InnoDB 表上效果一致：都是重建表（新建临时表 → 拷贝有效行 → 替换 .ibd → 删除旧文件），真正释放磁盘空间。但实操差异明显：
- OPTIMIZE TABLE t 在 MySQL 5.7+ 等价于 ALTER TABLE t FORCE，过程加 S 锁（允许读，但写性能抖动剧烈）
- ALTER TABLE t ENGINE=InnoDB 语义更直白，适合脚本批量操作；部分 RDS 默认启用 ALGORITHM=INPLACE，但需查 information_schema.INNODB_METRICS 确认是否真走 online DDL
- 两个命令都会在开始和结束抢一次 MDL 锁——若有慢查询或长事务卡着，命令会挂住不动，超时后报 Lock wait timeout exceeded
执行前必须检查的三件事
忽略任一条件都可能导致失败、锁库或磁盘爆满：
- 确认引擎是 InnoDB（SHOW CREATE TABLE t 查 ENGINE=InnoDB）——对 MEMORY、CSV 等无效
- 磁盘剩余空间 ≥ 当前表 Data_length 的 2 倍——重建过程要同时存新旧两个 .ibd 文件
- 没有活跃长事务或未提交 DML 占用该表——可通过 SELECT * FROM information_schema.INNODB_TRX 检查
碎片率高但不敢直接 OPTIMIZE 怎么办？
如果表太大、业务不能停、磁盘又吃紧，硬跑 OPTIMIZE TABLE 风险太高。这时可以：
- 先用 SELECT (DATA_FREE / DATA_LENGTH) AS frag_ratio FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db' AND TABLE_NAME = 't'; 算碎片率，> 0.25（25%）再考虑收缩
- 用 pt-online-schema-change 工具做在线重建，避免锁表，但要求额外磁盘空间和权限
- 对超大表，分批 DELETE + ALTER TABLE ... ENGINE=InnoDB 分区执行（如按时间分区），比全表重建更可控
- 注意：DROP 或 TRUNCATE 能立刻释放空间，但它们是 DDL，不可回滚，且会重置 AUTO_INCREMENT
真正释放空间这件事，本质不是“删完就完事”，而是“重建才生效”。容易被忽略的是：锁等待时间和磁盘双倍开销——这两个点一旦没卡准，操作就会卡死或失败，而不是静默完成。
