分区表迁移不可直接用mysqldump全量导出导入，因partition by兼容性差且–single-transaction易引发元数据锁；推荐方案依次为：逻辑导数据+手动建表、exchange partition单分区迁移、物理文件拷贝（需严格条件）、mysql 8.0+ clone plugin整库克隆，并须迁移后执行analyze table更新分区统计信息。
分区表迁移不能直接用 mysqldump 导出再导入
因为 mysqldump 默认导出的是建表语句 + INSERT，而分区表的 PARTITION BY 子句在目标库可能因版本、存储引擎或参数不兼容导致报错；更关键的是，mysqldump --single-transaction 在读取分区时可能触发元数据锁冲突，造成长时间阻塞。
实操建议：
- 优先使用
mysqldump --no-create-info --skip-triggers只导数据，再手动重建带分区的表结构 - 确认源库和目标库的 MySQL 版本一致（尤其 5.7 与 8.0 的
LIST COLUMNS和subpartition行为差异） - 导出前执行
SHOW CREATE TABLE，检查PARTITION定义中是否含函数（如TO_DAYS()）、时间格式或非标准字段类型，这些在低版本目标库上可能不支持
使用 ALTER TABLE … EXCHANGE PARTITION 跨库迁移单个分区
适用于目标库已存在相同结构的分区表，且只想迁移部分历史分区（比如只迁 2023 年以前的数据），避免全量拷贝。
注意前提条件：
- 源表和目标表必须使用相同存储引擎（通常为
InnoDB） - 两个表的列定义、索引、字符集、排序规则必须完全一致（连
NOT NULL和默认值都不能差） - 被交换的分区必须是空的，或者你先在目标端创建一个临时空表，再用
EXCHANGE把源分区“换”进来 - 执行前需关闭
foreign_key_checks和sql_mode中的严格模式，否则易报Error 1731
典型流程：CREATE TABLE t_new LIKE t_src; ALTER TABLE t_new REMOVE PARTITIONING; ALTER TABLE t_src EXCHANGE PARTITION p2022 WITH TABLE t_new; —— 这样就把 p2022 分区数据转成普通表 t_new，再通过 INSERT INTO ... select 或 mysqldump 迁移它。
物理文件拷贝需停写且校验 .ibd 文件完整性
当源库和目标库均为 InnoDB、同版本、同平台（linux x86_64）、且启用了 innodb_file_per_table 时，可考虑直接拷贝分区对应的数据文件（.ibd）。
但风险极高，务必注意：
- 必须确保该分区无任何未提交事务、无活跃 DML，建议在维护窗口内
FLUSH TABLES t WITH READ LOCK后操作 - 每个分区在磁盘上不是独立文件，而是由主表
.ibd内部管理；只有使用ALTER TABLE ... REORGANIZE PARTITION拆分后，配合DISCARD TABLESPACE才能拿到可迁移的.ibd - 拷贝后在目标库执行
ALTER TABLE t IMPORT TABLESPACE前，要用mysqlcheck --check-upgrade验证表空间兼容性，否则大概率报ERROR 1808（tablespace mismatch）
MySQL 8.0+ 推荐用 clone plugin 做整库克隆（含分区）
CLONE PLUGIN 是 MySQL 8.0.17+ 内置功能，能完整复制包括分区定义、数据、索引、表选项在内的整个实例或数据库，且自动处理一致性快照。
启用方式简单但限制明确：
- 源库和目标库必须都是 MySQL 8.0.17+，且
clone插件已安装（INSTALL PLUGIN clone SONAME 'mysql_clone.so'） - 目标实例必须为空（或指定新目录），不支持追加到已有库；克隆过程会覆盖目标数据目录
- 网络传输阶段默认走压缩（
clone_buffer_size可调），但跨机房迁移时若延迟高、丢包多，容易卡在Clone Donor State: Waiting - 克隆完成后，目标库的
auto_increment值、GTID 位置、binlog 文件名均重置，需人工同步复制位点（如果用于主从）
真正省事的场景是：测试环境快速拉取生产分区表快照。线上迁移仍建议搭配逻辑备份做双重验证。
分区迁移最常被忽略的点是 information_schema.PARTITIONS 视图里的 DATA_LENGTH 和 INDEX_LENGTH 在迁移后可能不准——需要对每个分区执行 ANALYZE TABLE t PARTITION(p2023) 手动更新统计信息，否则查询计划容易误判。