optimize table不是必须操作，而是满足碎片率超30%、无长事务、磁盘告急等条件时才值得执行的高代价重建手段；它通过创建新.ibd文件、顺序写入有效数据、原子替换来回收空间，但会锁表并需双倍磁盘空间。
OPTIMIZE TABLE 不是“必须”执行的操作，而是在特定条件下才值得考虑的高代价补救手段。InnoDB 删除数据后不释放磁盘空间，是设计使然，不是 bug。
为什么删完数据 .ibd 文件大小不变？
InnoDB 的 DELETE 操作本质是“标记删除”：它只把记录打上删除位、把页内空间加入空闲链表，但不会主动归还磁盘给操作系统。哪怕你删掉 90% 的数据，.ibd 文件尺寸仍岿然不动。
这种行为带来两个直接后果：
-
DATA_FREE值飙升（可通过SHOW TABLE STATUS LIKE 't1'查看） - 后续
INSERT会优先复用这些“空闲页”，但若新数据写入模式随机，反而加剧碎片和 B+ 树分裂
OPTIMIZE TABLE 真正干了什么？
它对 InnoDB 表等价于：ALTER TABLE t1 ENGINE=InnoDB —— 即重建整张表。
这个过程包括：
- 创建全新
.ibd文件 - 逐行扫描原表，把“未被标记删除”的记录顺序写入新文件
- 重建聚簇索引和所有二级索引
- 删除旧文件，原子切换表引用
所以它确实能回收空间、整理碎片、更新统计信息，但代价极重：
- MySQL 5.6–8.0 默认全程锁表（DML 阻塞），哪怕启用了
innodb_file_per_table=ON - 需要临时双倍磁盘空间：100GB 表 → 执行中瞬时占用 ≥200GB
- 主从延迟可能暴涨，尤其当 binlog 写入量激增时
什么时候才该用 OPTIMIZE TABLE？
仅当同时满足以下条件时，才值得冒风险执行：
-
DATA_FREE / Data_length > 0.3（即空闲空间占比超 30%） - 业务处于明确低峰期，且已确认无长事务阻塞 DDL（查
INFORMATION_SCHEMA.INNODB_TRX） - 磁盘空间告急，且没有更轻量方案可用（如分区
DROP PARTITION或分批TRUNCATE） - 确认表不含全文索引、外键、生成列等会导致
ALGORITHM=COPY的结构
否则，更推荐用 ALTER TABLE t1 ENGINE=InnoDB ALGORITHM=INPLACE LOCK=NONE 替代 —— 它语义更清晰，且在满足条件时真正支持在线操作。
真正该优先做的：从删除方式根治碎片
问题不在“删完要不要优化”，而在“怎么删”。一次性 DELETE FROM t WHERE ... 百万行，是碎片爆炸的源头。
更稳妥的做法：
- 用主键范围分片删除：
DELETE FROM t WHERE id BETWEEN 10000 AND 20000，每次 ≤1 万行，加SLEEP(0.1) - 日志类大表务必按时间分区，删旧数据直接
ALTER TABLE t DROP PARTITION p2024_q1—— 零 I/O、秒级、无碎片 - 清空整表优先选
TRUNCATE TABLE t（注意不可回滚、重置自增、需DROP权限） - 删除比例极高（>80%）时，用“新建表 + 插入保留数据 + 重命名”法，比
OPTIMIZE更可控
真正容易被忽略的点是：OPTIMIZE TABLE 解决的是表层症状，而分批删除、分区设计、TRUNCATE 使用时机，才是影响空间与性能的底层开关。
