能，OPTIMIZE TABLE 对 MyISAM 重建表并释放空间，对 InnoDB 则等价于 ALTER TABLE ... FORCE 重建聚簇索引；但需 innodb_file_per_table=ON 才能释放空间回操作系统，且执行时加 S 锁、可能阻塞业务。
OPTIMIZE TABLE 真的能清理碎片吗？
能，但只对 MyISAM 和 InnoDB 表生效，且行为完全不同。对 MyISAM，它会重建表、排序索引、释放空闲空间；对 InnoDB，本质是执行 ALTER TABLE ... FORCE，触发重建聚簇索引，顺便整理页碎片和释放未用空间。
常见错误现象：OPTIMIZE TABLE 执行完，data_length 没变小，甚至更大——大概率因为 InnoDB 的 innodb_file_per_table=OFF，数据写进共享表空间 ibdata1，优化后空间无法返还给操作系统。
- 必须确认
innodb_file_per_table=ON（查SHOW VARIABLES LIKE 'innodb_file_per_table'） -
OPTIMIZE TABLE期间，InnoDB表会加S锁（可读不可写），大表可能阻塞业务 - 不建议在从库上直接运行——可能造成主从延迟或复制中断（尤其 binlog_format=STATEMENT 时）
什么时候该跑 OPTIMIZE TABLE？
不是“碎片多就该清”，而是看是否真实影响性能或磁盘。关键指标来自 information_schema.TABLES：
重点关注 data_free（已分配但未用的空间）和 data_length / avg_row_length 推算的行数是否明显偏离实际行数。例如一张 100 万行的表，data_free 超过 500MB，且 avg_row_length 比正常值高 2–3 倍，才值得干预。
- 频繁
DELETE或UPDATE大字段（如 TEXT/BLOB）后没做维护 - 表经历过大量
INSERT ... ON DUPLICATE KEY UPDATE或批量REPLACE - 监控发现
InnoDB缓冲池命中率持续低于 95%，且排除其他原因后怀疑是页碎片导致随机 IO 上升 - 不要为“看着 data_free 很大”就执行——它可能是预留的空闲页，后续插入会复用
替代方案：ALERT TABLE ... ENGINE=InnoDB 更可控
对 InnoDB 表，OPTIMIZE TABLE 底层就是这个操作，但显式写出来更透明，也方便加参数控制。
比如想避免长事务阻塞，可以加 ALGORITHM=INPLACE（需 MySQL 5.6+，且仅支持部分 DDL）；想控制临时空间用量，可用 LOCK=NONE（要求主键不变、无全文索引等条件）。
- 安全起见，优先试
ALTER TABLE t ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=SHARED; - 如果报错
ALGORITHM=INPLACE is not supported，说明涉及不支持的变更（如修改列类型），退回到ALGORITHM=COPY（等价于 OPTIMIZE） - 执行前务必确认磁盘剩余空间 ≥ 当前表
data_length + index_length，否则会失败
清理后空间没释放？检查 ibdata1 和 tmpdir
即使 innodb_file_per_table=ON，如果 tmpdir 空间不足，OPTIMIZE 或 ALTER 过程中生成的临时文件可能失败，或回退到低效路径；更隐蔽的是，若早期建过 MyISAM 表又删了，ibdata1 里仍存着它的回滚段残留，这部分空间永远无法回收。
- 查临时目录：运行
SELECT @@tmpdir;，确保对应磁盘剩余 ≥ 表大小 × 1.5 - 查
ibdata1是否膨胀：ls -lh /var/lib/mysql/ibdata1，超几 GB 且长期不降，基本说明有历史遗留问题 - 真正释放
ibdata1只能重做实例：导出 SQL → 删除全部文件 → 重启初始化 → 导入，生产环境慎用
碎片清理不是定期保养动作，而是针对性排障手段。最容易被忽略的，是把 data_free 当成“垃圾”，却没验证它是否真被引擎视为可回收空间——尤其是当 innodb_page_size 是 64KB 且表里大量短文本时，页面利用率天然偏低，那点 data_free 可能根本不是问题。
