MySQL 迁移时 CREATE TABLE
中的 PARTITION BY
会被忽略吗？
不会被忽略，但是否生效取决于目标 MySQL 版本和存储引擎。MySQL 8.0.26+ 的 InnoDB 支持原生分区，但 8.0.25 及更早版本对分区表迁移支持脆弱；尤其是从 MySQL 5.7 迁移到 8.0 时，
PARTITION BY RANGE或
PARTITION BY LIST子句若含不兼容语法（如使用了已废弃的
KEY(partition_col)写法），会导致
CREATE TABLE失败。 迁移前用
SHOW CREATE TABLE tbl_name导出建表语句，检查
PARTITION BY块是否完整、语法是否符合目标版本规范 MySQL 8.0.24+ 不再支持
LINEAR HASH分区，若源表使用该类型，需先在源库转为标准
HASH或改用
RANGE COLUMNS使用
mysqldump --no-create-info+ 手动重建表结构的方式，比全量 dump 更可控——可先在目标库执行 clean 的
CREATE TABLE（不含数据），再导入数据
分区键字段在迁移后查询变慢，常见原因有哪些？
分区裁剪（partition pruning）失效是主因，通常不是迁移本身导致，而是迁移后执行计划退化或统计信息未更新。
目标库未运行ANALYZE TABLE tbl_name，优化器仍沿用旧的空/过期分区统计，误判为需扫描全部分区 WHERE 条件中分区键用了函数或隐式类型转换，例如
WHERE DATE(created_at) = '2024-01-01'或
WHERE partition_id = '123'（字段是
INT，传入字符串），导致无法裁剪 分区表达式含非确定性函数（如
NOW()、
UUID()），MySQL 无法静态推导分区归属，强制全分区扫描 使用
mysqldump --single-transaction导出时，若源表有长事务正在写入，可能导致部分分区数据版本不一致，迁移后范围查询结果异常
跨实例迁移时，如何安全保留分区结构并避免锁表？
不能依赖
ALTER TABLE ... REORGANIZE PARTITION在目标库重建，那会引发锁表；应优先采用逻辑迁移+预建分区策略。 用
SELECT ... INTO OUTFILE按分区导出数据：例如
SELECT * FROM tbl PARTITION(p2023) INTO OUTFILE '/tmp/p2023.csv'，再用
LOAD DATA INFILE导入目标表对应分区 目标表必须提前建好且分区定义完全一致（包括分区名、边界值、子分区数），否则
LOAD DATA会报错
ERROR 1728 (HY000): Cannot load data into partitioned table with mismatched partitions若源表使用
LIST COLUMNS分区，注意 MySQL 5.7 和 8.0 对 NULL 值处理差异：5.7 允许 NULL 匹配任意 LIST 分区，8.0 要求显式声明
VALUES IN (NULL)，迁移前需校验 禁止在目标库直接
ALTER TABLE ADD PARTITION后再导入——新分区无数据，但查询可能路由到空分区，返回空结果而不报错
使用 mysqlpump
还是 mysqldump
处理分区表更稳妥？
mysqlpump在 8.0.21+ 对分区表支持更好，但默认并发导出会打乱分区数据顺序；
mysqldump更保守，适合强一致性要求场景。
mysqlpump --include-tables=db.tbl --skip-definer --set-gtid-purged=OFF可导出带分区的建表语句，但需加
--default-parallelism=1避免多线程写入导致同一分区数据错序
mysqldump --tab生成的
.sql+
.txt文件天然按表粒度分离，配合
sed提取单个分区的
INSERT语句较方便，适合做灰度迁移 两者均不自动处理分区索引统计，迁移后务必在目标库执行
ANALYZE TABLE，否则
EXPLAIN PARTITIONS显示的
partitions列可能为空或错误
EXPLAIN PARTITIONS SELECT * FROM orders WHERE order_date >= '2024-01-01'; -- 若输出中 partitions 字段为 NULL 或显示 all，说明分区裁剪未触发，别急着调优查询，先查 ANALYZE 是否执行
分区迁移真正难的不是语法兼容，而是边界值精度、时区隐含转换、以及跨版本统计信息模型差异——这些细节在
SHOW WARNINGS里往往只字不提。
