外键存在时alter table ... discard tablespace会报错，必须先禁用外键检查、成组迁移依赖表、按父→子顺序导出导入，并在import tablespace后手动重建外键约束，同时确保字符集与排序规则一致。
外键存在时直接ALTER TABLE ... DISCARD TABLESPACE会报错
遇到 ERROR 1031 (HY000): Table storage engine for 'xxx' doesn't have this option 或 ERROR 1217 (HY000): Cannot delete or update a parent row: a foreign key constraint fails，基本就是外键在拦路。InnoDB 在启用 foreign_key_checks=1 时禁止对含外键约束的表执行 DISCARD TABLESPACE —— 这是硬限制，不是配置能绕开的。
必须先临时禁用外键检查，但要注意：禁用后不会自动删外键定义，只是跳过校验；导入后若目标库要保留外键，得手动重建。
- 源库导出前，确认外键依赖关系：查
SELECT CONSTRAINT_NAME, TABLE_NAME, COLUMN_NAME, REFERENCED_TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'your_db' AND REFERENCED_TABLE_SCHEMA IS NOT NULL; - 目标库建表前，先执行
SET FOREIGN_KEY_CHECKS = 0;，建完所有关联表再SET FOREIGN_KEY_CHECKS = 1; -
DISCARD TABLESPACE前必须确保该表没被其他表作为外键引用（即它是“叶子表”），否则即使关了检查也会失败
迁移含外键的表必须成组操作，不能单表孤立搬运
外键本质是表间强依赖，单独迁 orders 表而漏掉 customers，哪怕物理文件拷过去，IMPORT TABLESPACE 时也会因 schema mismatch 或 page checksum 失败直接中断。
正确做法是把整套外键链涉及的表一起处理，且导出/导入顺序必须是：先父表、后子表。
- 导出时，在源库按依赖顺序执行
FLUSH TABLES customers, orders, order_items FOR EXPORT;（注意顺序） - 拷贝时，确保
.ibd和.cfg文件一一对应，名字大小写、路径层级必须完全一致（尤其开启lower_case_table_names=1的实例） - 目标库建表时，字段名、类型、索引、外键定义（不含 CONSTRAINT 名）需严格一致；字符集、
ROW_FORMAT、innodb_page_size必须相同，否则报Schema mismatch
IMPORT TABLESPACE 后外键不自动生效，需手动修复
表空间导入只恢复数据和索引结构，不恢复外键约束定义。即使你建表时写了 FOREIGN KEY (customer_id) REFERENCES customers(id)，只要没显式 ADD CONSTRAINT，这个约束就不存在 —— SHOW CREATE TABLE 里看不到 CONSTRAINT 关键字。
常见误操作：以为导入完就万事大吉，结果业务写入时报 Cannot add or update a child row 才发现约束丢了。
- 导入后立即执行
ALTER TABLE orders ADD CONSTRAINT fk_orders_customer FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE CASCADE; - 如果原约束名已存在（比如从备份还原），加
IF NOT EXISTS避免报错（MySQL 8.0.19+ 支持） - 验证是否生效：
SELECT * FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'orders' AND CONSTRAINT_SCHEMA = 'your_db';
跨版本迁移时外键语法兼容性更麻烦
MySQL 5.7 导出的外键语句在 8.0+ 导入可能失败，典型错误是 ERROR 3780 (HY000): Referencing column 'id' and referenced column 'id' in foreign key constraint 'fk_xxx' are incompatible. —— 根本原因是排序规则（collation）或隐式转换规则变了。
别指望 --compatible=mysql56 能兜住所有问题，它只降级语法，不处理底层 collation 冲突。
- 导出前统一源库和目标库的字符集与排序规则，例如都设为
utf8mb4_unicode_ci，避免用utf8mb4_0900_as_cs - 建表语句中显式声明
COLLATE utf8mb4_unicode_ci，别依赖默认值 - 若目标库是 MySQL 9.6.0（2026 年新版本），外键已上移到 SQL 层，导入后需确认
information_schema.INNODB_FOREIGN是否为空，非空才说明约束真正注册成功
外键迁移最易被忽略的点不是命令怎么敲，而是依赖拓扑没理清、字符集没对齐、约束没重建这三件事——它们不出现在任何一条报错里，却会让数据在静默中失去完整性保障。
