optimize table会导致长时间锁表，因其在innodb中本质是重建表：全程持有mdl写锁，阻塞所有dml和部分ddl；大表下耗时可达数分钟至小时。
OPTIMIZE TABLE 为什么会导致长时间锁表
MySQL 的 OPTIMIZE TABLE 在 InnoDB 引擎下本质是重建表：先创建新表、拷贝数据、重建索引、再原子替换。这个过程在 MySQL 5.6–8.0 多数版本中会全程持有 MDL（metadata lock） 写锁，阻塞所有 DML（INSERT/UPDATE/DELETE）和部分 DDL，直到操作完成。尤其当表很大（比如 >10GB）、磁盘慢或 buffer pool 不足时，耗时可能达数分钟甚至小时。
替代方案：用 ALGORITHM=INPLACE 避免全表重建
从 MySQL 5.6 起，OPTIMIZE TABLE 对 InnoDB 表默认等价于 ALTER TABLE ... ENGINE=InnoDB，但你可以显式改用在线 DDL 模式，跳过锁表重建：
- 对已存在主键和索引的表，直接运行：
ALTER TABLE t1 ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE; -
ALGORITHM=INPLACE表示复用原表结构，在原地整理碎片、重建索引；LOCK=NONE表示不阻塞读写（前提是满足在线 DDL 条件） - 必须确保该表没有全文索引、无虚拟列、且 MySQL 版本 ≥5.6.17；否则会自动降级为
COPY算法并锁表 - 执行前可用
SHOW CREATE TABLE t1;检查是否含不支持在线 DDL 的特性
生产环境更安全的做法：pt-online-schema-change
当无法确认是否支持 ALGORITHM=INPLACE，或表极其庞大、业务对延迟极度敏感时，应放弃原生命令，改用 Percona Toolkit 的 pt-online-schema-change：
- 它通过创建影子表 + 触发器 + 增量同步方式实现“无锁优化”，全程允许读写
- 命令示例：
pt-online-schema-change --alter "ENGINE=InnoDB" D=test,t=users --execute - 注意：需确保主从延迟可控、binlog_format=ROW、触发器未被禁用；执行期间会额外占用约 2 倍磁盘空间
- 比原生命令慢，但可中断、可监控、失败后残留少——这是线上兜底的首选
最容易被忽略的细节：OPTIMIZE 并不总能提升性能
很多人以为 OPTIMIZE TABLE 是“数据库保养”，但实际效果高度依赖场景：
- 仅当表经历过大量
DELETE或短生命周期行（如日志表）导致页碎片严重时，才可能有明显收益 - 对于写入密集但无删除的表（如订单流水），
OPTIMIZE后反而可能因 B+ 树重新填充降低局部性，首次查询变慢 - MySQL 8.0+ 的
innodb_defragment参数和后台线程已能自动整理碎片，人工干预必要性大幅下降 - 真正需要关注的是
information_schema.INNODB_SYS_TABLESTATS中的AVG_ROW_LENGTH和DATA_FREE，而非盲目定期执行
