MySQL中DELETE不释放磁盘空间是InnoDB正常设计，仅标记为可复用；OPTIMIZE TABLE可回收空间但有风险，推荐用ALTER TABLE ENGINE=InnoDB或pt-online-schema-change等低影响方案。
MySQL Delete后空间不释放是常态，不是Bug
InnoDB表执行DELETE语句后，数据行被标记为“可复用”，但物理磁盘空间不会立即归还给操作系统。这是InnoDB的设计机制：页内空闲空间优先用于后续INSERT或UPDATE，以减少页分裂和I/O开销。只有当整页变为空且被从B+树中彻底移除时，才可能触发空间回收——但这需要满足严格条件（如页合并、索引重组），日常DML几乎不会触发。
Optimize Table真能回收空间？看存储引擎
OPTIMIZE TABLE对不同引擎效果差异极大：
- InnoDB：本质是
ALTER TABLE ... FORCE，重建表并释放碎片，最终调用innodb_file_per_table=ON时的TRUNCATE + INSERT SELECT逻辑，可显著减小.ibd文件大小 - MyISAM：真正执行碎片整理，重写.MYD/.MYI文件，释放磁盘空间
- 注意：
OPTIMIZE TABLE在只读实例或主从复制环境中会阻塞写入，且期间占用额外磁盘空间（临时表）
替代方案：更安全、低影响的在线操作
生产环境慎用OPTIMIZE TABLE，尤其大表。推荐以下路径：
- 确认是否真需回收：先查
information_schema.TABLES，对比DATA_LENGTH与INDEX_LENGTH之和 vsDATA_FREE，若DATA_FREE远小于总大小，说明碎片不严重 - 用
ALTER TABLE t ENGINE=InnoDB代替OPTIMIZE TABLE——效果相同，语义更明确，部分MySQL 8.0+版本支持ALGORITHM=INPLACE（仅限无锁重建） - 对超大表，拆分执行：
pt-online-schema-change --alter "ENGINE=InnoDB" D=test,t=orders，避免锁表和主从延迟 - 长期预防：设置
innodb_page_cleaners > 1、监控Innodb_buffer_pool_pages_free，定期清理过期数据而非全量DELETE
执行Optimize Table前必须检查的3件事
跳过这些检查，极大概率导致失败或雪崩：
- 磁盘剩余空间 ≥ 当前表
DATA_LENGTH + INDEX_LENGTH（OPTIMIZE会先建新表，旧表不删直到完成） - 确认
innodb_file_per_table=ON（否则OPTIMIZE无法缩小系统表空间ibdata1） - 检查复制状态：
SHOW SLAVE STATUS\G中Seconds_Behind_Master为0，且SQL_THREAD未暂停；否则从库可能因DDL卡住
DATA_FREE显示值受innodb_fill_factor影响，并非真实浪费。先看指标，再动手。 
