迁移后表空间碎片未消失，是因为mysqldump等工具仅逻辑导出导入或xtrabackup直接拷贝.ibd文件，绕过innodb页管理机制，原库空洞、低填充页及未清理的delete-mark记录被完整继承，且迁移过程不触发purge或页重组。
迁移后表空间碎片严重，不是迁移本身造成的，而是迁移过程绕过了InnoDB的页管理机制，直接拷贝了带空洞的.ibd文件——原库中已存在的碎片被原样继承，且迁移后没有触发Purge或页重组。
为什么mysqldump / xtrabackup迁移后碎片没消失
MySQL迁移工具（如mysqldump、mydumper、甚至物理备份恢复）默认不重建页结构：
-
mysqldump导出的是SQL逻辑语句，导入时按主键顺序重插，但若原表主键非递增（如UUID）、或导入期间有并发写入，仍会引发页分裂和新碎片 -
xtrabackup恢复是直接复制.ibd文件，原表所有空洞、低填充率页、未清理的delete-mark记录全部保留 - 即使使用
mysqlpump加--skip-definer或--set-gtid-purged=OFF，也不改变InnoDB页级物理布局
如何在线回收空间（不锁表或最小化锁）
InnoDB本身不支持“在线清空碎片”，但可通过以下方式在业务可接受范围内完成空间回收：
- 用
ALTER TABLE t ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE（MySQL 5.6+）：仅当表无全文索引、无虚拟列、无外键引用时才真正免锁；否则自动降级为LOCK=SHARED（允许读，阻塞写） - 对大表优先用
pt-online-schema-change：它通过影子表+触发器同步增量，全程读写不受影响，但要求binlog_format=ROW且从库延迟可控 - 避免用
OPTIMIZE TABLE：它在MySQL 8.0+中对InnoDB等价于ALTER TABLE ... REBUILD，但会强制升级为LOCK=EXCLUSIVE（完全阻塞读写），且无法指定ALGORITHM
执行前必须验证的三个硬性条件
跳过任一检查，操作大概率失败或卡住：
- 确认
innodb_file_per_table为ON：SELECT @@innodb_file_per_table;返回1；否则ALTER TABLE不会释放空间到文件系统 - 确保磁盘剩余空间 ≥ 当前.ibd文件大小 × 2：重建过程需同时保留旧表和新表文件，临时空间不足会导致操作中断并回滚
- 检查是否存在长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 300;；若有活跃超5分钟事务，ALTER TABLE会等待其结束
回收后.ibd文件没变小？先看data_free是否归零
别急着删文件或怀疑命令失效——ibd文件大小不缩小，常见于：
- 操作系统层面未启用
innodb_file_per_table，或表属于系统表空间（ibdata1），此时空间只能被InnoDB复用，无法返还OS - 执行成功但
data_free仍较大：说明Purge线程尚未清理完delete-mark记录，可手动触发：SET GLOBAL innodb_purge_rseg_trx_ips = 1;（MySQL 8.0.23+） - 文件系统未启用TRIM（如ext4挂载未加
discard选项），即使InnoDB标记空间可回收，OS也无法感知
