分区表迁移不可直接用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) 手动更新统计信息,否则查询计划容易误判。










