是，表碎片率超20%时应优先optimize table而非盲目建索引，它能同时重建聚簇索引和所有二级索引、提升页填充率；但需注意锁表现象、磁盘空间及主从复制影响。
表数据量大后 SELECT 明显变慢，是不是该优化索引？
不一定。很多情况下不是索引没建好，而是表本身存在大量碎片，导致磁盘读取效率下降、缓冲池命中率降低。尤其在频繁 DELETE 或 UPDATE 大量行后，InnoDB 的页分裂和空洞积累会直接拖慢全表扫描和范围查询。
- 先确认是否真有碎片：查
information_schema.TABLES，对比DATA_LENGTH和DATA_FREE，若DATA_FREE / DATA_LENGTH > 0.2（即碎片率超20%），就值得处理 - 别急着重建索引——
OPTIMIZE TABLE会同时重建表+索引，对大表是更直接有效的方案 - 注意：执行期间表会被锁（MySQL 5.6+ 对 InnoDB 是在线 DDL，但仍有短暂排他锁；MySQL 8.0 支持真正 Online，但仍需看具体操作类型）
OPTIMIZE TABLE 执行卡住或报错怎么办？
常见错误如 ERROR 1036 (HY000): Table is read only 或长时间无响应，往往和存储引擎、权限或磁盘空间有关。
- 确保表是
InnoDB引擎（MyISAM虽也支持OPTIMIZE，但行为不同且已不推荐） - 检查磁盘剩余空间：临时需要约等于原表大小的空闲空间（因为会创建新表再原子替换）
- 避免在主从复制环境中对大表直接
OPTIMIZE——它会生成一个完整ALTER TABLE ... FORCE类型的 binlog，可能压垮从库 IO - 如果只是想释放碎片又不想锁太久，可改用
ALTER TABLE t ENGINE=InnoDB（效果等同OPTIMIZE，但语义更明确）
重建索引比 OPTIMIZE TABLE 更轻量？
不是。单独重建某个索引（比如用 ALTER TABLE t DROP INDEX idx_a, ADD INDEX idx_a (col)）看似精准，但实际开销未必小，还容易遗漏隐式主键/唯一约束带来的二级索引连锁影响。
-
OPTIMIZE TABLE会统一整理聚簇索引（主键）和所有二级索引，保证 B+ 树结构紧凑、页填充率合理 - 手动
DROP + ADD索引无法回收主键页内的碎片，对SELECT *或覆盖索引外的查询帮助有限 - 若只想重建单个索引且表极大，可用
ALGORITHM=INPLACE, LOCK=NONE（MySQL 5.6+），但需确认该索引字段未被其他外键或全文索引依赖
清理完还是慢？重点检查这三点
碎片和索引只是表层原因，很多“优化后无效”的情况其实卡在更底层。
- 确认是否用了
SELECT *查了大字段（TEXT/BLOB）——即使加了索引，回表时仍要读取整行，碎片影响放大 - 检查
innodb_buffer_pool_size是否足够：若远小于数据总大小，每次OPTIMIZE后缓存冷启动，首条查询必然慢 - 留意统计信息是否过期：
OPTIMIZE TABLE不自动更新索引基数（cardinality），必要时补一句ANALYZE TABLE t
碎片清理不是银弹，它只解决物理存储层的低效。真正卡点常藏在查询写法、缓冲区配置或执行计划误判里——别让 OPTIMIZE 成为掩盖慢查询的惯性操作。
