能，但仅对启用独立表空间（innodb_file_per_table=on）的innodb表有效；optimize table通过重建表回收碎片，若使用共享表空间（ibdata1）则完全无效。
OPTIMIZE TABLE 真的能回收碎片吗？
能，但只对 InnoDB 表有效，且前提是你没开启 innodb_file_per_table=OFF。如果所有表共用系统表空间（ibdata1），OPTIMIZE TABLE 对它完全无效——哪怕你跑了几十次，ibdata1 也不会变小。这是最常被忽略的前提。
真正起作用的是：InnoDB 重建表（ALTER TABLE ... FORCE 或 OPTIMIZE TABLE 在 5.6+ 默认走 ALGORITHM=COPY）+ 启用独立表空间 + 表数据实际有可释放的空闲页。
- 确认是否启用独立表空间：
SHOW VARIABLES LIKE 'innodb_file_per_table';，必须为ON - 检查表是否真的存在碎片：对比
data_length + index_length和磁盘上.ibd文件大小，差值大才值得优化 - 线上执行会锁表（COPY 算法下是“全表 DML 阻塞”），别在高峰期跑
为什么 OPTIMIZE TABLE 有时没效果？
常见假象：执行完 OPTIMIZE TABLE t1;，SELECT data_length + index_length FROM information_schema.tables 数值没降，或者 ls -lh t1.ibd 文件大小几乎不变。原因往往不是命令错了，而是：
- 表刚经历过大批量 DELETE，但没触发页合并（InnoDB 不会自动把空页还给文件系统，除非重建）
- 表里有大量长文本（
TEXT/BLOB），它们可能存储在单独的溢出页（off-page），OPTIMIZE不一定整理这些区域 - MySQL 8.0+ 默认用
ALGORITHM=INPLACE优化某些操作，但OPTIMIZE TABLE在 8.0 仍默认走COPY；而如果你手动加了ALGORITHM=INPLACE，它其实等价于ALTER TABLE t1 ENGINE=InnoDB，但不会重建二级索引（所以碎片清理不彻底）
替代方案：ALTER TABLE ENGINE=InnoDB 更可控
这和 OPTIMIZE TABLE 底层行为一致，但更透明、更易加参数控制。尤其适合想跳过统计信息更新、或明确指定算法的场景。
- 强制重建（等效传统 OPTIMIZE）：
ALTER TABLE t1 ENGINE=InnoDB, ALGORITHM=COPY; - 想减少锁时间（8.0+）：
ALTER TABLE t1 ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE;—— 但注意：这不释放碎片，只重组织聚簇索引 - 避免 ANALYZE TABLE 自动触发（影响查询计划缓存）：
ALTER TABLE t1 ENGINE=InnoDB, STATS_AUTO_RECALC=0;
执行前务必确认磁盘剩余空间 ≥ 当前表 .ibd 大小，因为重建过程会先写新文件，再原子替换。
碎片整理后，为什么查询没变快？
碎片影响的是 I/O 效率（页分散 → 随机读增多），不是 CPU 或 SQL 写法。如果瓶颈在索引缺失、JOIN 顺序、或缓冲池命中率低，光整理碎片毫无意义。
- 查缓冲池使用率：
SHOW ENGINE INNODB STATUS\G里的Buffer pool hit rate，低于 99% 才值得优先调大innodb_buffer_pool_size - 确认慢查询是否真走索引：
EXPLAIN FORMAT=JSON看used_columns和access_type -
.ibd缩小了，但SELECT COUNT(*)还很慢？大概率是没走索引扫描，而是全表扫 —— 碎片和这个无关
碎片整理是“保养”，不是“治病”。它解决不了逻辑设计缺陷，也掩盖不了配置失当。
