直接用alter table t_name engine=innodb可清理innodb表空间碎片，效果等同optimize table且语义更明确；需查data_free字段确认是否真需清理——>100mb或占比>5%才干预，data_free=0时执行纯属浪费io。
直接用 ALTER TABLE t_name ENGINE=InnoDB 就能清理 InnoDB 表的空间碎片，效果和 OPTIMIZE TABLE 完全一致，且语义更明确、协作更安全。
怎么确认该表真需要清理碎片？
别凭感觉判断“删了很多数据”，必须查 DATA_FREE 字段：
-
SHOW TABLE STATUS LIKE 't_name'→ 看Data_free列（单位字节）；值 > 100MB 或占Data_length + Index_length超过 5% 才值得动 - 批量筛查：运行
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不代表绝对无碎片（比如页内碎片），但此时执行ALTER TABLE ... ENGINE=InnoDB不会改变文件大小，纯属浪费 IO
为什么用 ALTER TABLE 而不是 OPTIMIZE TABLE？
两者底层都是重建表，但行为差异直接影响操作可维护性：
-
OPTIMIZE TABLE是“黑盒命令”，容易被误认为轻量级维护，实际锁表、耗空间、还可能静默跳过压缩表（MySQL 5.7 某些小版本） -
ALTER TABLE t_name ENGINE=InnoDB明确表达了“我要重建这张表”，团队协作时意图清晰，日志/审计也更易追溯 - 加
ALGORITHM=INPLACE对碎片无效——InnoDB 碎片整理必须拷贝全量数据，这个参数只影响加索引等 DDL，别白加 - MySQL 8.0+ 支持
LOCK=NONE，但仅限部分 DDL 场景；对ENGINE=InnoDB仍需LOCK=DEFAULT（即写锁），不能绕过
执行前必须检查的三件事
跳过检查大概率卡住、失败或白跑：
- 确认引擎是 InnoDB：
SHOW CREATE TABLE t_name→ 必须看到ENGINE=InnoDB；MyISAM 表用这个命令会报错 - 确认独立表空间开启：
SELECT @@innodb_file_per_table;返回1才有效；返回0说明所有表共用ibdata1，ALTER TABLE根本无法回收磁盘空间 - 检查磁盘剩余空间 ≥ 当前
.ibd文件大小的 1.5 倍；用ls -lh /var/lib/mysql/db_name/t_name.ibd查真实大小，别信Data_length
常见卡死/失败现象和对应解法
执行后长时间没反应或报错，基本就这几种情况：
- 卡在
Waiting for table flush→ 用SHOW PROCESSLIST;查是否有长事务未提交，必须 kill 或等其结束 - 报错
ERROR 1036 (HY000): Table 't_name' is read only→ 主库或从库开了read_only=1或super_read_only，需临时关闭 - 报错
ERROR 1795 (HY000): ALTER operation not supported→ 表是分区表的某个子分区，或用了不支持的存储格式（如ROW_FORMAT=COMPRESSED且 MySQL 版本有 bug） - 执行完
.ibd大小不变 → 先查innodb_file_per_table是否为 0，再确认有没有其他进程正在写该表（如 binlog dump、备份工具）
真正麻烦的不是命令本身，而是重建过程要申请新段、逐行拷贝、释放旧页——它不“整理”碎片，是彻底换一套房子住。磁盘空间、事务状态、引擎配置，三者缺一不可，漏查一个就白等半小时。
