MySQL 信创化迁移至 PolarDB-X 整体实施方案

一、方案概述

1. 项目背景

现有业务运行在自建 MySQL 5.7/8.0 （x86），按照信创改造要求，迁移至信创硬件部署的 PolarDB-X 2.0（分布式版）；实现数据库国产化替代、分布式弹性扩展，同时保障业务平滑迁移、数据零丢失、具备完整回滚能力。

PolarDB-X 信创底座：支持海光 x86、鲲鹏 / 飞腾 ARM ；操作系统适配银河麒麟 V10、统信 UOS V20、openEuler、龙蜥 AnolisOS。分为专有云本地部署（信创私有化）、阿里云飞天企业版两种交付形态。

2. 迁移目标

1. 完成 MySQL 单体→PolarDB-X 分布式架构改造（分库分表规划）；
2. 全栈信创适配：国产服务器 + 国产 OS+PolarDB-X；
3. 业务不停机平滑迁移，支持灰度切换、故障快速回切；
4. 迁移后性能、稳定性满足业务 SLA；
5. 满足信创安全规范（三员、审计、SSL 加密、权限管控）。

3. 架构对比

表格

现有 MySQL 架构	目标 PolarDB-X 分布式架构
单体 / 主从 MySQL，垂直扩容瓶颈	CN 计算节点 + DN 存储节点 + GMS 全局元数据，水平弹性扩缩容
AUTO_INCREMENT 自增（单机唯一）	分布式 Sequence 全局唯一
本地事务，跨库事务无保障	支持分布式事务（2PC）、单分片事务优化
外键、触发器、存储过程广泛使用	分布式场景不推荐外键 / 触发器，需应用改造

二、整体实施阶段划分

阶段 1：迁移评估 & 信创环境准备（1～2 周） 阶段 2：库表结构改造、分片设计、应用 SQL 适配（2～4 周） 阶段 3：数据迁移方案验证、功能 & 性能测试（2～3 周） 阶段 4：灰度流量切换、试运行（1～2 周） 阶段 5：正式割接、旧库下线、运维体系落地

三、阶段详细方案

阶段 1：迁移评估与信创环境搭建

1.1 源库摸底评估（核心）

（1）基础信息采集

• MySQL 版本、字符集、隔离级别、数据量、增量 TPS、峰值 QPS；
• 对象清单：表、视图、存储过程、触发器、事件、函数、外键；
• 慢 SQL、大事务、无主键表、JOIN 关联表、批量 DML；

sql

-- 统计表容量
SELECT table_schema,SUM(data_length+index_length)/1024/1024 AS size_mb
FROM information_schema.tables GROUP BY table_schema;

（2）兼容性风险扫描（重点）

PolarDB-X 不兼容 / 弱兼容清单：

1. ❌ 不支持外键级联、触发器、EVENT 事件、空间几何类型；
2. ⚠️ 存储过程支持受限，禁止存储过程内动态 SQL (PREPARE)；
3. ❌ :=变量赋值、STRAIGHT_JOIN、HANDLER 语法；
4. ❌ 单机自增 ID 跨分片冲突，必须替换为PolarDB-X Sequence；
5. 不支持跨分片外键，关联逻辑上移至应用；
6. DDL 语法差异：建表需要定义分片规则。

工具：PolarDB-X 官方迁移评估工具，自动扫描不兼容 SQL 与对象。

1.2 信创 PolarDB-X 集群规划

硬件选型（信创）

• 海光 7000/8000（x86）或鲲鹏 920 / 飞腾 FT-2000+（ARM）；
• 存储：NVMe SSD，禁止机械盘；生产 DN 建议一主两副本；

集群角色规划

• CN（计算节点）：SQL 解析、路由、结果聚合；根据并发水平横向扩容；
• DN（存储节点）：真实数据存储（MySQL 内核）；分片落地在 DN；
• GMS：全局元数据、事务 TSO 时钟；
• CDC（可选）：增量同步、binlog 输出，用于数据同步、数据湖。

网络与安全（信创要求）

• 集群内部网络低延迟，建议万兆；
• 开启 SSL 数据库连接审计、操作日志审计；
• 三员权限分离（系统管理员、安全管理员、审计管理员）；
• 白名单、账号最小权限策略。

阶段 2：分片设计 & 业务改造（最关键环节）

两种模式选型： ① 不分片模式（单库模式） ：业务量不大，仅做信创迁移，不分库分表；DDL 和 MySQL 基本一致，改造最小； ② 分布式分片模式：大数据量表，进行水平拆分，充分发挥分布式能力。

2.1 表类型定义（PolarDB-X 三种表）

1. 分片表（Partition Table） ：业务主表，按 ShardingKey 水平拆分；

   sql

   CREATE TABLE `order` (
     id BIGINT,
     order_no VARCHAR(32),
     user_id BIGINT
   ) ENGINE=InnoDB
   DBPARTITION BY HASH(user_id) DBPARTITIONS 8;

2. 广播表（Broadcast Table）：基础字典表，每个 DN 全量存储（区域、配置字典）；

3. 单表（Single Table）：小表，存储在指定 DN，无拆分。

2.2 分片键选择原则

✅ 优先查询条件高频字段；尽量避免跨分片 JOIN； ❌ 不要使用更新频繁字段作为分片键；

跨分片查询会产生全分片扫描，严重影响性能，尽可能通过业务设计规避。

2.3 重点改造清单

1. 自增主键改造 废弃AUTO_INCREMENT，使用分布式 Sequence：

sql

CREATE SEQUENCE seq_order START WITH 1 INCREMENT BY 1;
-- 应用获取：SELECT NEXT VALUE FOR seq_order;

1. 移除所有外键、触发器，关联校验逻辑下沉应用；
2. 改造存储过程：剔除动态 SQL，复杂逻辑迁移至服务层；
3. SQL 改造：
   • 禁止依赖单机排序、limit offset 超大分页；
   • 避免不带分片键的全表更新 / 删除；
   • 优化跨分片 JOIN，优先使用广播表关联分片表；
4. 连接池适配（HikariCP）

yaml

spring.datasource.hikari:
  connection-timeout: 5000
  idle-timeout: 900000
  max-lifetime: 1200000
  maximum-pool-size: 32
  connection-test-query: SELECT 1

1. JDBC 驱动：继续使用标准 mysql-connector，协议兼容 MySQL，无需更换驱动。

阶段 3：数据迁移方案（3 种可选方案）

前提：源 MySQL 开启 binlog，格式ROW，GTID 建议开启。

方案 A：DTS 全量 + 增量同步（推荐，不停机迁移）

适用：生产在线业务，追求平滑割接

1. 结构先行 ：在 PolarDB-X 创建分片表、广播表（不能直接 mysqldump 导入表结构，缺少分片定义）；
2. DTS 配置：源 = 自建 MySQL，目标 = PolarDB-X； 任务：全量数据迁移 + 增量 binlog 同步；
3. 全量完成后持续追增量，观察同步延迟稳定 < 5s；
4. 开启两端数据一致性校验； ✅ 优点：官方工具、断点续传、监控完善； ⚠️ 限制：DDL 同步兼容性有限，迁移期间尽量避免大表 DDL。

方案 B：mysqldump 全量导入 + 原生 binlog 复制（私有化信创环境无 DTS 时）

1. 源库加只读锁 / 使用--single-transaction一致性导出数据（只导出数据，不导出建表语句）；
2. 在 PolarDB-X 执行预建好带分片规则的表结构；
3. 导入 dump 数据；
4. 搭建 MySQL→PolarDB-X binlog 异步复制持续追增量；

适合离线私有化信创场景，无云 DTS 服务。

方案 C：停机迁移（仅允许业务短时中断场景）

mysqldump 导出→导入 PolarDB-X；业务停机窗口割接；风险最低，影响最大。

数据一致性校验方案

1. 基础：行数、总行数对比；
2. 进阶：按分片抽样校验、checksum 比对；
3. 工具：DTS 内置校验 / 自研数据比对程序；

割接前必须连续 3 轮校验无差异。

阶段 4：流量切换策略（灰度 + 双写，降低风险）

推荐切换路线（风险由低至高）

1. 增量同步持续运行，MySQL 为主库；
2. 开启应用双写（主写 MySQL，异步冗余写入 PolarDB-X）；持续观察写入成功率、异常；
3. 灰度放行读流量：10% → 30% → 50% → 80% → 100% 读流量切 PolarDB-X；
4. 全部读流量稳定运行无故障后，切换写流量；
5. 保持双写观察 7 天；确认稳定后，关闭双写，旧 MySQL 改为只读；

回滚预案（重中之重，信创项目必备）

任意阶段出现异常：

1. 切回读写流量至源 MySQL；
2. 增量同步任务保持运行，故障修复后可再次尝试割接；

禁止直接下线源 MySQL，建议保留至少 15 天。

阶段 5：测试体系

1. 功能测试：所有业务接口验证，重点分页、事务、批量操作；
2. 兼容性测试：存储过程、函数、SQL 语法；
3. 压力性能测试：模拟生产峰值，对比原 MySQL 吞吐、响应时间；
4. 故障演练：DN 节点宕机、CN 扩容、主从切换，验证集群高可用；
5. 信创专项测试：国产 CPU、麒麟操作系统稳定性、安全审计。

四、风险清单与应对措施

表格

风险点	应对方案
大量跨分片 SQL，性能恶化	迁移前 SQL 评审，调整分片键、业务逻辑，引入广播表
自增 ID 冲突	统一使用分布式 Sequence，禁止依赖 auto_increment
触发器 / 外键无法迁移	应用层实现约束逻辑，提前改造代码
迁移期间源库压力突增	DTS 限流，业务低峰执行全量迁移
割接后死锁、事务超时	优化分布式事务范围，避免长事务；调整锁等待超时参数
信创 ARM 架构性能波动	NUMA 绑核、操作系统内核参数调优；DN 内存参数优化
数据不一致	割接前多轮数据校验；过渡期双写兜底

五、运维体系建设（迁移完成后）

1. 监控大盘：CN/DN CPU、内存、IO、分片延迟、跨分片查询占比；
2. 慢 SQL 审计、锁分析、分布式事务监控；
3. 备份策略：PolarDB-X 逻辑备份 + 快照备份；
4. 容灾方案：同机房多副本；重要业务规划跨机房部署；
5. 信创安全运维：定期审计日志、权限巡检、漏洞补丁管理。

六、交付物清单

1. 《MySQL 迁移 PolarDB-X 信创方案总体设计》
2. 《分片设计规范 & 建表 SQL 脚本》
3. 《SQL 兼容性改造清单》
4. 《数据迁移操作手册 + 回滚预案》
5. 《灰度切换割接方案》
6. 《信创环境部署与参数优化规范》
7. 《测试报告、性能压测报告》
8. 《上线运维手册》