optimize table会导致长时间锁表，因其在innodb中执行的是重建表操作：创建临时表、逐行拷贝数据、重建索引、原子替换，全程持有mdl排他锁，阻塞所有dml和多数ddl。
OPTIMIZE TABLE 为什么会导致长时间锁表
OPTIMIZE TABLE 在 InnoDB 中不是原子操作，它实际执行的是“重建表”：先创建空的临时表、逐行拷贝数据、重建索引、再原子替换原表。整个过程会持有 MDL（metadata lock） 排他锁，阻塞所有 DML（INSERT/UPDATE/DELETE）和大部分 DDL，直到重建完成。尤其对大表（比如千万级以上），这个过程可能持续数分钟甚至更久，线上服务直接卡住。
用 ALGORITHM=INPLACE 替代 OPTIMIZE TABLE
MySQL 5.6+ 的 InnoDB 支持 ALGORITHM=INPLACE 的在线 DDL，它能避免全表拷贝，大幅缩短锁表时间。对多数碎片整理场景，ALTER TABLE ... ENGINE=InnoDB 就能达到 OPTIMIZE TABLE 的效果，且默认走 inplace 模式（只要没显式指定 ALGORITHM=COPY）。
- 推荐写法：
ALTER TABLE t1 ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE; -
LOCK=NONE表示不阻塞 DML（前提是满足 online DDL 条件，如无全文索引、无虚拟列等） - 执行前务必确认表结构兼容性——可先在测试库跑
SHOW CREATE TABLE t1对比 - 注意：
ALGORITHM=INPLACE不支持 MyISAM 表，也不适用于ROW_FORMAT或KEY_BLOCK_SIZE的变更
用 pt-online-schema-change 做真正零停机优化
当表太大、或业务无法容忍任何 DML 阻塞（哪怕几秒），pt-online-schema-change（Percona Toolkit）是更稳妥的选择。它通过创建影子表、触发器同步增量、逐步拷贝数据、最后原子切换的方式，实现“几乎无锁”的表优化。
- 基本命令：
pt-online-schema-change --alter "ENGINE=InnoDB" D=test,t=t1 --execute - 全程只在最后切换瞬间加短暂元数据锁（毫秒级），不影响业务读写
- 必须确保主从延迟可控、磁盘空间充足（需额外 100% 空间）、且表有主键或唯一非空索引（否则无法安全同步）
- 运行时会持续检查复制延迟和负载，若超阈值自动暂停，适合生产环境灰度使用
哪些情况其实根本不需要 OPTIMIZE TABLE
很多人一看到“碎片率高”就下意识跑 OPTIMIZE TABLE，但 InnoDB 的碎片对性能影响远不如想象中严重。以下情况通常无需优化：
- 表
Data_free值小于 10MB，或碎片率（Data_free / Data_length）低于 25%，一般无实际收益 - 业务以点查为主、且已有合适二级索引，B+ 树页分裂对查询路径影响极小
- 使用了
innodb_file_per_table=ON（默认），碎片只影响单表文件大小，不污染系统表空间 - 频繁写入的表，刚优化完几分钟又产生新碎片，属于无效劳动
真正值得警惕的是 SHOW TABLE STATUS 中 Rows 明显少于 Data_length / avg_row_length 的偏差，才暗示可能存在严重逻辑碎片或统计信息失真——这时优先考虑 ANALYZE TABLE 更新统计信息，而非重建表。
