OPTIMIZE TABLE 能释放磁盘空间，但需满足 innodb_file_per_table=ON、无长事务、磁盘空间充足等前提；本质是重建表（等价 ALTER TABLE ENGINE=InnoDB），否则无效甚至失败。
OPTIMIZE TABLE 能释放磁盘空间，但**不是万能的，且在 InnoDB 中它本质就是 ALTER TABLE ... ENGINE=InnoDB，会锁表、耗空间、有前提条件**。盲目执行可能卡住、失败，甚至没效果。
怎么判断表真有碎片？看 DATA_FREE，别猜
碎片是否严重，不能靠“删了很多数据”这种感觉来判断。必须查 information_schema.tables 的 DATA_FREE 字段：
-
DATA_FREE是 InnoDB 表中当前可复用但尚未归还操作系统的字节数（仅当innodb_file_per_table = 1时有意义） - 单表检查：
SHOW TABLE STATUS LIKE 'your_table';→ 看Data_free列（单位字节） - 批量筛查碎片 > 100MB 的表：
SELECT CONCAT(table_schema,'.',table_name) AS tbl, sys.FORMAT_BYTES(data_free) AS free, (data_free / (data_length + index_length)) AS pct FROM information_schema.tables WHERE engine = 'InnoDB' AND data_free > 100*1024*1024 ORDER BY data_free DESC LIMIT 10;
- 注意：
DATA_FREE为 0 不代表绝对无碎片（比如页内碎片），但 > 5% 或 > 1GB 就值得干预
OPTIMIZE TABLE 为什么经常没反应？常见失效原因
执行后 .ibd 文件大小纹丝不动，大概率踩进了以下坑：
-
innodb_file_per_table关闭了：查SELECT @@innodb_file_per_table;，返回0就是关的；此时所有表共用ibdata1，OPTIMIZE TABLE根本无法把空间还给操作系统 - 表上有长事务未提交：
OPTIMIZE会卡在Waiting for table flush，用SHOW PROCESSLIST;能看到；必须等事务结束或 kill 掉 - 磁盘临时空间不足：重建过程需额外空间 ≥ 当前
.ibd大小；若只剩 20GB，而表文件 25GB，命令会失败或卡死 - 用了压缩表（
ROW_FORMAT=COMPRESSED）：MySQL 5.7 某些小版本对压缩表OPTIMIZE静默跳过，不报错也不生效
比 OPTIMIZE TABLE 更可控的替代操作
生产环境建议优先用 ALTER TABLE ... ENGINE=InnoDB，语义清晰、行为可预期：
- 基础写法：
ALTER TABLE your_table ENGINE=InnoDB;—— 效果等同于OPTIMIZE TABLE，但不会被误认为“只是优化”，更利于协作理解 - 加
ALGORITHM=INPLACE？别指望：该参数对碎片回收无效（只影响某些 DDL 如加索引），InnoDB 碎片整理必须重建表，强制拷贝数据 - 想降低风险？搭配
LOCK=NONE（MySQL 8.0+）或使用pt-online-schema-change工具实现在线操作，避免业务阻塞 - 执行后务必跟一句：
ANALYZE TABLE your_table;—— 更新统计信息，否则优化器可能继续走坏执行计划
真正释放空间的关键：不只是执行命令
即使 ALTER TABLE 成功，.ibd 缩小了，磁盘空间也不一定立刻“可用”。因为：
- Linux 下文件系统不自动合并空闲块，
df显示的空间可能滞后；但ls -lh看.ibd大小已变小，说明空间已被 InnoDB 释放 - 如果用的是云数据库（如阿里云 RDS），后台可能启用自动碎片回收，但只处理 5–100 GB 的表，且要求实例 CPU ≥ 4核、剩余空间 ≥ 3倍表大小——这些限制常被忽略
- 最彻底的清理方式其实是：停写、导出（
mysqldump）、删库、重装 MySQL 并确保innodb_file_per_table = 1、再导入；但这属于“手术级”操作，日常运维中极少采用
