DELETE后磁盘空间不释放是InnoDB和MyISAM的设计机制，仅标记行为空闲供复用，不归还OS；OPTIMIZE TABLE仅在碎片率超30%、独立表空间启用、磁盘充足且低峰期时才值得执行。

不是“必须”，而是“在特定条件下才值得考虑”。MySQL执行大量 DELETE 后，OPTIMIZE TABLE 既不自动触发，也不总是有效，更不推荐无脑执行。

为什么 DELETE 后磁盘空间不释放？

InnoDB 和 MyISAM 都不会立即将已删行占用的物理空间归还给操作系统——它们只标记页内空间为“可复用”。这是设计使然，不是 bug。

• InnoDB：删除后页仍保留在缓冲池中，空闲页供后续 INSERT 复用；但 .ibd 文件大小不变，Data_free 值上升
• MyISAM：.MYD 文件大小完全不变，已删行仅打标记，无自动合并机制
• 两者共性：碎片是静默累积的，业务无感知，直到磁盘告警或慢查询突增才暴露

OPTIMIZE TABLE 真正起作用的场景有哪些？

它只在满足以下全部条件时才有实际价值：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• SHOW TABLE STATUS LIKE 't'\G 中 Data_free > Data_length × 0.3（即碎片率超 30%）
• 表引擎是 InnoDB 且 innodb_file_per_table=ON（否则优化无效，ibdata1 不释放）
• 或表引擎是 MyISAM（此时 Data_free 恒为 0，需靠 Data_length 与实际数据量对比判断）
• 业务低峰期，且磁盘剩余空间 ≥ 当前表文件总大小（.ibd 或 .MYD + .MYI）

为什么 OPTIMIZE TABLE 很容易踩坑？

它表面是“优化”，实则是高风险重建操作：

• 全程独占锁：InnoDB 表在 MySQL 8.0 前仍阻塞所有 DML；MyISAM 阻塞写、只允许读（但读可能被挂起）
• 双倍磁盘开销：临时生成新文件期间，磁盘瞬时占用翻倍，df -h 不提前看，大概率写满宕机
• 主从延迟爆炸：DDL 写入 binlog，从库串行重放，大表优化可能卡住 SQL Thread 数小时
• 退化风险：InnoDB 的 ALTER TABLE ENGINE=InnoDB 若含全文索引、外键或虚拟列，会 silently 降级为 COPY 模式，锁更久

比 OPTIMIZE 更稳妥的替代方案

真正治本的方式，是改“删法”，而不是删完再“擦屁股”：

• 分批删除：DELETE FROM t WHERE id BETWEEN ? AND ?，每次 ≤ 1w 行，配合 SLEEP(0.05)
• 时间分区表：对日志类表用 PARTITION BY RANGE (TO_DAYS(created_at))，直接 DROP PARTITION p_old
• 清空优先：TRUNCATE TABLE（不可回滚，但零碎片、秒级、不走 undo）
• 在线重建（推荐）：ALTER TABLE t ENGINE=InnoDB ALGORITHM=INPLACE LOCK=NONE，前提是无全文索引/外键/虚拟列

最容易被忽略的一点：很多团队在监控里只看 Data_free，却没意识到 MyISAM 表这个值永远是 0；而 InnoDB 表若 Data_free 是 2GB，但 Data_length 是 200GB，其实碎片率才 1%，根本不值得动 OPTIMIZE。