ibdata1无法自动缩小，即使删除所有表也不会释放磁盘空间；唯一可靠方法是导出全库、初始化新实例并导入，前提需确认innodb_file_per_table=ON已生效。
ibdata1 不会自动缩小，哪怕你删光所有表、关掉共享表空间，它也不会释放磁盘空间。唯一可靠办法是导出 + 重建实例。
确认当前是否已启用独立表空间
这是所有操作的前提。MySQL 8.0+ 默认开启，但初始化方式不当（比如用 --initialize-insecure 或跳过配置文件）可能导致仍沿用旧行为。
- 执行
SELECT @@innodb_file_per_table;，返回1才表示生效 - 若为
0，需在my.cnf中显式添加innodb_file_per_table = ON并重启 MySQL - 注意：该参数只影响新创建的表，对已有表无作用
把大表从 ibdata1 迁移到独立 .ibd 文件
适用于已存在、且当前数据实际存于共享表空间（ibdata1）中的 InnoDB 表。
- 执行
ALTER TABLE my_table ENGINE=InnoDB;即可触发重建，新数据将按当前innodb_file_per_table设置写入独立.ibd文件 - 该操作会锁表（即使 MySQL 8.0+，也仅
ALGORITHM=INSTANT支持极简变更；改引擎属于全量重建） - 磁盘空间必须 ≥ 当前表大小 × 2：一份用于临时表，一份保留原表（直到重建完成）
- 执行后
ibdata1体积不会变小——InnoDB 不回收已分配的共享表空间空间
物理迁移单张表（跨库/跨实例）
依赖 innodb_file_per_table = ON 和表空间传输（Transportable Tablespace），比 mysqldump 更快、更轻量。
- 源库先执行
FLUSH TABLES my_table FOR EXPORT;，确保数据落盘并获取一致的.cfg元数据文件 - 复制三样东西到目标库对应数据库目录：
my_table.ibd、my_table.cfg（MySQL 5.7+）、my_table.frm（5.7 及以前）或my_table.sdi（8.0+） - 目标库先建同结构空表（
CREATE TABLE ... ENGINE=InnoDB），再执行ALTER TABLE my_table DISCARD TABLESPACE;，再复制文件过去，最后ALTER TABLE my_table IMPORT TABLESPACE; - 漏掉
.cfg或未FLUSH ... FOR EXPORT会导致import失败，报错类似Tablespace is not encrypted but encryption flag is set
别碰 innodb_data_file_path 和 innodb_undo_directory
这两个参数属于“初始化即锁定”型配置，运行中修改等于直接让 MySQL 启动失败。
-
innodb_data_file_path = ibdata1:12M:autoextend:max:5G只应在首次初始化前设置；线上实例改了就起不来 -
innodb_undo_directory在 MySQL 8.0.14+ 已废弃；undo 表空间默认放在数据目录下，命名为undo_001、undo_002等；如需指定路径，必须配合innodb_undo_tablespaces，且只能在初始化时完成 - 看到
ibdata1没增长，不等于它没在干活——undo log、change buffer、数据字典仍在其中，I/O 压力可能很高；用SHOW ENGINE INNODB STATUS\G查LOG和UNDO LOG部分更准
真正棘手的地方不在怎么迁，而在于：迁完之后 ibdata1 依然占着几十 GB 不放，监控告警照响；很多 DBA 试过 OPTIMIZE TABLE、TRUNCATE、甚至删库，结果发现只是把问题藏得更深了。
