optimize table在mysql 5.6+的innodb表上本质是重建表（algorithm=copy），能回收碎片并释放物理空间，但需满足innodb_file_per_table=on、data_free显著偏高且无长事务等条件，否则无效；替代方案alter table engine=innodb algorithm=inplace可避免锁表但不缩磁盘文件。
Optimize Table 对 InnoDB 表到底有没有用？
直接说结论：OPTIMIZE TABLE 在 MySQL 5.6+ 的 InnoDB 表上，**本质是重建表（ALGORITHM=COPY）**，能回收碎片、释放物理空间，但代价高——会锁表、耗时长、产生大量 I/O。它不是“整理碎片”的轻量操作，而是“删掉旧表 + 重建新表 + 拷贝数据”的重操作。
常见误解是把它当 VACUUM（PostgreSQL）或 SHRINK SPACE（Oracle）来用，但 InnoDB 没有原地收缩机制，OPTIMIZE TABLE 是唯一内置的“强制收缩”手段，前提是满足条件。
什么情况下执行 OPTIMIZE TABLE 才真正释放磁盘空间？
必须同时满足以下三点，否则磁盘文件大小不会变小：
-
innodb_file_per_table = ON（默认从 MySQL 5.6 起启用；若为 OFF，所有表共享ibdata1，OPTIMIZE TABLE无法释放空间） - 表之前发生过大量
DELETE或UPDATE（尤其是大字段修改），导致页内空闲空间未被复用，且DATA_FREE值显著（可通过SHOW TABLE STATUS LIKE 'tbl_name'查看） - 执行后确认
ibd文件大小减小（Linux 下用ls -lh /var/lib/mysql/db_name/tbl_name.ibd对比）
注意：即使满足以上条件，如果 innodb_page_size 较大（如 64K），或存在长事务/undo 日志未清理，也可能导致空间回收不彻底。
替代方案：ALGORITHM=INPLACE 更安全但不缩空间
MySQL 5.6+ 支持 ALTER TABLE ... ENGINE=InnoDB ALGORITHM=INPLACE，它也能重建表，但不锁 DML（仅需短时间元数据锁），且不生成临时文件。但它不会收缩 ibd 文件——只是重新组织页，DATA_FREE 可能归零，但磁盘大小不变。
所以如果你只想要“逻辑紧凑”，用这个；如果目标是“磁盘瘦身”，还是得走 OPTIMIZE TABLE 或更激进的方式（如 mysqldump 导出再导入）。
示例命令：
ALTER TABLE orders ENGINE=InnoDB ALGORITHM=INPLACE LOCK=NONE;
执行前必须检查的三个风险点
OPTIMIZE TABLE 看似简单，但线上误操作极易引发故障：
- 检查磁盘剩余空间是否 ≥ 当前表
Data_length + Index_length（重建过程需双倍空间） - 确认没有长事务或正在运行的备份（如
mysqldump --single-transaction会与OPTIMIZE冲突） - 避免在主库高峰时段执行；从库执行前先
STOP SLAVE，否则可能因 relay log 应用延迟导致主从不一致
最常被忽略的是：InnoDB 表在 OPTIMIZE 过程中，information_schema.INNODB_SYS_TABLES 中的 SPACE 值会变化，监控脚本若依赖该值判断表状态，可能误报。
