会锁表，且是全表独占锁；OPTIMIZE TABLE 在 MySQL 中会重建表并阻塞读写，InnoDB 5.6+ 虽支持部分在线 DDL，但默认仍非真正在线，建议避开业务高峰并确认引擎类型。
OPTIMIZE TABLE 会锁表吗？生产环境能不能直接跑
会锁表，而且是全表独占锁——optimize table 在 mysql（尤其是 myisam 和老版本 innodb）中会先重建表，期间写入完全阻塞，读也可能被阻塞（取决于隔离级别和引擎）。innodb 从 5.6 开始支持在线 ddl 的部分操作，但 optimize table 默认仍不是真正“在线”的；它底层调用的是 alter table ... force 或 rebuild，本质仍是拷贝重建。
实操建议：
- 避开业务高峰，尤其不能在订单提交、支付回调等核心链路活跃时段执行
- 确认存储引擎：
SHOW CREATE TABLE <code>your_table看ENGINE=InnoDB还是MyISAM；MyISAM 更危险，锁更重 - MySQL 5.7+ 且使用 InnoDB 时，可改用
ALTER TABLE <code>your_tableENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE（需满足条件），比OPTIMIZE TABLE更可控 - 监控锁等待：
SELECT * FROM performance_schema.data_locks或SHOW PROCESSLIST中看状态是否卡在Waiting for table metadata lock
碎片到底有没有？别靠感觉，用 SQL 查真实值
很多 DBA 看到“慢查询”就下意识 OPTIMIZE TABLE，但表未必真有碎片。InnoDB 表的“碎片”主要体现为页内空闲空间未回收、二级索引 B+ 树深度异常、或 DATA_FREE 显著偏高。盲目优化可能白忙活，甚至引发主从延迟。
查真实碎片程度：
- 运行
SELECT TABLE_NAME, DATA_LENGTH, INDEX_LENGTH, DATA_FREE, TABLE_ROWS FROM information_schema.TABLES WHERE TABLE_SCHEMA = '<code>your_db' AND TABLE_NAME = 'your_table' -
DATA_FREE > 0且远大于单页大小（16KB）才值得警惕；比如DATA_FREE = 268435456（256MB）说明有大量未复用空间 - 对比
DATA_LENGTH + INDEX_LENGTH和磁盘上实际文件大小（ls -lh /var/lib/mysql/<code>your_db/your_table.ibd），若后者大出很多，说明物理文件没收缩 - 检查索引深度：
SELECT NAME, N_ROWS, SPACE, FILE_SIZE, ALLOCATED_SIZE FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE '<code>your_db/your_table'（需开启innodb_stats_persistent）
OPTIMIZE TABLE 和 ALTER TABLE … REBUILD 有什么区别
表面看都是“重建表”，但行为细节差异直接影响风险和效果。MySQL 官方文档明确说 OPTIMIZE TABLE 对 InnoDB 就是 ALTER TABLE ... FORCE 的别名，但实际执行路径受参数和版本影响很大。
关键差异点：
-
OPTIMIZE TABLE会强制更新统计信息（ANALYZE TABLE），而ALTER TABLE ... REBUILD不会自动触发，得额外执行 -
OPTIMIZE TABLE在遇到损坏页时可能失败并报错ERROR 1030 (HY000): Got error 168 from storage engine；ALTER TABLE ... ALGORITHM=INPLACE在支持场景下容错性略好 - 对带全文索引（FULLTEXT）的表，
OPTIMIZE TABLE会重建 FT 索引，ALTER TABLE ... REBUILD则不会（除非显式指定DROP/ADD） - 如果表启用了压缩（
ROW_FORMAT=COMPRESSED），OPTIMIZE TABLE可能改变压缩率，而ALTER TABLE ... ROW_FORMAT=COMPRESSED更明确可控
执行后为什么查询没变快？常见失效原因
优化完发现 QPS 没涨、慢查照旧，大概率不是碎片问题，而是误判了瓶颈根源。碎片清理只解决存储层的空间利用率和页分裂问题，对其他性能瓶颈毫无作用。
典型失效场景：
- 慢查询主因是缺失索引或索引失效，
EXPLAIN显示type=ALL或rows过大——这时加索引比OPTIMIZE TABLE有效十倍 - 缓冲池（
innodb_buffer_pool_size）太小，数据频繁换入换出，碎片减少也掩盖不了 I/O 压力 - 表上有长事务未提交，
OPTIMIZE TABLE生成的新版本数据页会被旧 MVCC 版本拖累，SELECT仍要遍历旧链 - 执行后没及时收集统计信息（尤其低版本 MySQL），优化器继续用过期的行数估算，选错执行计划
- 应用层连接池缓存了旧的执行计划（如 MySQL 8.0+ 的
PREPARE语句计划），需DEALLOCATE PREPARE或重启连接
碎片清理是个精确手术，不是万能补药。真正要盯住的，永远是 EXPLAIN 结果、information_schema 里的真实指标、以及 slow_query_log 里排在前面的那几条 SQL。
