OPTIMIZE TABLE对MyISAM表能回收DELETE/UPDATE产生的空闲空间，因其通过LOCK→CREATE NEW TABLE→COPY&REBUILD→DROP OLD三步重建表结构，紧凑写入新文件并删除旧文件，从而释放操作系统级磁盘空间。
直接说结论：OPTIMIZE TABLE 对 MyISAM 表确实能回收因 DELETE 或 UPDATE 产生的空闲空间，但前提是表没被其他线程锁住，且磁盘要有足够临时空间 —— 否则命令会静默失败或卡住。
为什么 OPTIMIZE TABLE 能回收 MyISAM 空闲空间
MyISAM 的数据文件（.MYD）和索引文件（.MYI）在大量 DELETE 后会留下碎片化空洞，这些空间不会自动归还给操作系统。而 OPTIMIZE TABLE 实际上是执行三步操作：LOCK → CREATE NEW TABLE → COPY & REBUILD → DROP OLD。它重建整个表结构，把数据紧凑写入新文件，旧文件被删除，空闲空间自然释放。
注意：这不是“压缩”操作，而是彻底重写；所以它不适用于正在被高并发写入的生产表。
执行 OPTIMIZE TABLE 前必须检查的 4 件事
- 确认存储引擎是 MyISAM：
SHOW CREATE TABLE table_name;中看到ENGINE=MyISAM - 确保磁盘剩余空间 ≥ 当前表
.MYD + .MYI文件大小之和（OPTIMIZE期间会同时存在新旧两个完整副本） - 检查是否有长事务或未提交的写操作：
SHOW PROCESSLIST;中避免出现Locked或Copying to tmp table卡住的状态 - 避开业务高峰 —— 它会加
WRITE锁，阻塞所有 INSERT/UPDATE/DELETE，只允许 SELECT（但可能被挂起直到锁释放）
常见失败现象和对应原因
执行 OPTIMIZE TABLE t1; 后返回 OK 但磁盘空间没变？大概率是磁盘满导致中间步骤失败，MySQL 没报错但悄悄回退了。此时查错误日志（通常是 /var/log/mysql/error.log）会看到类似：
Warning 1286: Unknown storage engine 'InnoDB'
—— 别被这个误导，它常出现在磁盘满时的兜底日志里。更可靠的判断方式是执行后立刻运行：
SELECT data_length + index_length FROM information_schema.tables WHERE table_schema='db_name' AND table_name='t1';
对比优化前后数值是否下降。如果没变，基本就是失败了。
替代方案：当 OPTIMIZE TABLE 不可用时
如果无法停写、磁盘紧张，或只是想快速清理小范围空洞，可以考虑手动重建：
- 用
mysqldump导出再导入（更安全但耗时更长） - 建新表：
CREATE TABLE t1_new LIKE t1;→INSERT INTO t1_new SELECT * FROM t1;→RENAME TABLE t1 TO t1_old, t1_new TO t1; - 对超大表，可分批导出+清空+重建，但需自行处理外键和触发器
MyISAM 没有在线 DDL 支持，所有重建操作都绕不开锁表。真正要规避这类问题，长期看得迁移到 InnoDB 并开启 innodb_file_per_table，不过那是另一个故事了。
