InnoDB中OPTIMIZE TABLE常不释放磁盘空间，因其等价于ALTER TABLE ENGINE=InnoDB重建表，仅当innodb_file_per_table=ON、无元数据锁且使用独立表空间时才可能回收空间；Data_free不变未必失败，需结合平均行大小、删除比例及慢查询特征综合判断是否真需优化。
OPTIMIZE TABLE 在 InnoDB 表上经常“没效果”，不是命令写错了，而是它根本没真正释放空间回磁盘——除非你满足几个硬性前提。
为什么 OPTIMIZE TABLE 对 InnoDB 常常不降 Data_free
它在 InnoDB 里实际等价于 ALTER TABLE t ENGINE=InnoDB，本质是重建表。但重建能否把空闲页还给操作系统，取决于：
-
innodb_file_per_table必须为ON（默认从 5.6 起开启，但老实例或手动关过就可能不是） - 表不能被长事务、未提交的 DELETE/UPDATE 持有元数据锁（
SHOW PROCESSLIST看是否有Waiting for table metadata lock） - 如果用的是共享表空间（
ibdata1），Data_free再大也收不回磁盘——这个值只反映内部空闲页，不等于可回收空间 - 执行后
Data_free不变 ≠ 失败，可能只是当前空洞已足够被后续 INSERT 复用，物理页没被真正“挤掉”
别只盯着 Data_free，先判断碎片是否真该处理
单纯看 Data_free > 0 容易误判。真正需要干预的信号是：
-
SELECT (data_length + index_length) / table_rows AS avg_row_size FROM information_schema.tables结果远大于你业务行的实际字节数（比如字段加起来才 150 字节，却算出 1.8KB） - 历史
DELETE比例长期高于 30%，且之后几乎没有INSERT或UPDATE回填 - 慢查询日志中频繁出现
Using temporary; Using filesort，且EXPLAIN显示rows远大于filtered * rows（说明 B+ 树深度失衡或页内空洞拖慢扫描）
比 OPTIMIZE TABLE 更可控的替代操作
生产环境直接跑 OPTIMIZE TABLE 风险高。按场景选更稳妥的方式：
- 小表（
data_length ）：用 <code>ALTER TABLE t ENGINE=InnoDB，语义明确，兼容性好 - 大表且需低影响：用
pt-online-schema-change --alter "ENGINE=InnoDB" D=db,t=t，支持无锁重建，但依赖触发器和额外磁盘空间 - 只想提升页利用率（不改结构）：先
ALTER TABLE t ROW_FORMAT=DYNAMIC（比 COMPACT 更省空间），再OPTIMIZE TABLE - 确认
innodb_file_per_table=ON后，重建前可加SET SESSION sort_buffer_size = 268435456（256MB），加速排序阶段
OPTIMIZE TABLE 会重置 AUTO_INCREMENT 吗？
InnoDB 表不会。但重建过程本身会重新计算自增值——如果表里最大 ID 是 10000，中间删掉了一部分，重建后新插入的第一行 ID 可能仍是 10001，而不是从“空洞”里找最小可用值。这点和 MyISAM 不同，MyISAM 的 OPTIMIZE TABLE 会显式重置计数器。
最容易被忽略的一点：碎片清理不是“越勤越好”。频繁重建会放大 I/O 压力，尤其在 SSD 上还会加速磨损。建议结合监控（比如每周扫一次 DATA_FREE / (DATA_LENGTH + INDEX_LENGTH) > 0.3 的表），只对真正影响性能的表动手。
