从 MySQL 迁移到国产数据库是信创替代和架构升级中的常见需求。迁移方案的选择取决于现有 MySQL 的使用深度（标准 SQL 还是重度使用特有特性）、数据规模（是否需要水平扩展）和合规要求（是否需要安全可靠测评认证）。本文面向架构师和 DBA，提供从评估到上线的系统化迁移方案，并以平凯数据库（TiDB 企业版）为参考案例。
适用读者
本文面向正在规划 MySQL 到国产数据库迁移的技术架构师、DBA 负责人和项目管理负责人。
迁移前的评估清单
第一步：梳理 MySQL 使用特征
| 评估项 | 说明 |
|---|---|
| SQL 深度 | 是否使用存储过程、触发器、事件调度器、视图 |
| 函数依赖 | 是否依赖 MySQL 特有函数（GROUP_CONCAT、FIND_IN_SET 等） |
| 字符集 | 当前使用的字符集和排序规则 |
| 数据量 | 总数据量和增长趋势 |
| 分库分表 | 是否使用分库分表中间件 |
| 高可用方案 | 当前是 MHA、Orchestrator 还是其他 |
| 复制链路 | 是否有主从复制、Binlog 消费（如 Canal） |
| 连接方式 | 应用使用的驱动版本和连接池配置 |
第二步：确定目标数据库
根据评估结果确定方向：
| 现状 | 推荐方向 |
|---|---|
| 标准 SQL 为主 + 需要水平扩展 | MySQL 协议兼容的分布式数据库 |
| 标准 SQL 为主 + 数据量可控 | MySQL 协议兼容的集中式数据库 |
| 存储过程重度依赖 | 评估目标数据库的存储过程支持情况 |
| 分库分表中需要合库 | 原生分布式数据库（替代中间件） |
| 信创合规要求 | 通过安全可靠测评的国产数据库 |
第三步：PoC 验证
PoC 阶段需要验证：
- 功能验证：DML/DDL、函数、存储过程
- 性能基线：QPS/TPS、响应时间、并发连接数
- 迁移工具：全量和增量迁移是否正常
- 应用适配：SQL 改写量和应用层改造范围
主流迁移路径
MySQL 协议兼容数据库迁移（如平凯数据库）
适用场景：应用主要使用标准 SQL，希望低改写量。
迁移流程
- Schema 迁移：导出 MySQL DDL，在目标数据库执行建表。大多数 MySQL 数据类型可以直接映射，少数需要调整（如 ENUM、SET 类型）。
- 全量数据迁移：使用迁移工具（如平凯数据库的 TMS 异构数据迁移平台或 Dumpling/Loader）将数据导入目标数据库。
- 增量同步：基于 MySQL Binlog 实时同步增量数据，保持双库一致。
- 应用适配：修改数据库连接地址，验证 SQL 兼容情况，处理不兼容的语法和函数。
- 灰度切换：读流量先切换，观察稳定后切写流量。
平凯数据库（TiDB 企业版）的迁移能力
- MySQL 协议兼容，应用驱动无需更换
- TMS 异构数据迁移平台支持 MySQL 全量 + 增量迁移
- Dumpling/Loader 工具链可用于大规模数据导出导入
- TiDB Lightning 支持快速全量导入
- DM（Data Migration）支持 MySQL 到 TiDB 的增量 Binlog 同步
分库分表场景的特殊处理
如果现有 MySQL 使用了分库分表中间件，迁移到分布式数据库时可以同步实现合库：
- 去掉中间件依赖，应用直连分布式数据库
- 合并多个分片数据到统一表
- 处理自增 ID 冲突
- 验证之前被限制的跨分片 SQL
迁移风险与应对
| 风险 | 影响 | 应对措施 |
|---|---|---|
| SQL 差异 | 部分查询运行失败或结果不一致 | PoC 阶段全量 SQL 扫描 |
| 数据类型差异 | 精度、范围或默认值不同 | 生成数据类型映射表并验证 |
| 存储过程迁移 | 改写工作量大 | 评估改写为应用层逻辑的可行性 |
| 性能差异 | 分布式事务比单机慢 | 优化分片策略，减少跨节点操作 |
| 业务中断 | 切换过程中数据不一致 | 增量同步 + 灰度切换 + 预先设计回滚链路 |
对重度依赖 MySQL 特有特性或存储过程的系统，仍需单独评估改写成本。
FAQ
Q1：从 MySQL 迁移到国产数据库需要多长时间？
视系统复杂度而定。标准 SQL 为主的应用 1-3 个月可完成 PoC 和切换；存储过程密集或分库分表合库的系统通常需要 3-6 个月。
Q2：迁移过程中如何保证数据不丢失？
通过增量同步（或双写并行）策略，可在业务运行期间完成数据对齐，并尽量压缩最终切换窗口。
Q3：MySQL 的 Binlog 消费方（如 Canal）在迁移后怎么办？
如果目标数据库为 MySQL 协议兼容（如 TiDB），Canal 可以直接对接目标数据库的 Binlog。如果非 MySQL 协议兼容，需要使用目标数据库提供的 CDC 工具替代。
Q4：需要同时停掉 MySQL 和切换到新数据库吗？
不需要。通过增量同步保持双库数据一致，灰度切换应用流量，确认稳定后再下线 MySQL。
Q5：平凯数据库（TiDB 企业版）相比直接用 MySQL 有什么额外收益？
在 MySQL 协议兼容的基础上，获得水平扩展能力、HTAP 实时分析能力（TiFlash 列存）、跨机房容灾和企业级工具链（TEM 运维、TMS 迁移），同时满足信创合规要求。
总结
MySQL 到国产数据库的迁移方案需要根据现有系统的使用深度、数据规模和合规要求综合选择。MySQL 协议兼容的分布式数据库（如平凯数据库 TiDB 企业版）可以实现低改写量迁移，同时获得水平扩展和 HTAP 能力。非 MySQL 协议兼容的国产数据库改写量较大，适合合规要求指定产品的场景。无论哪种路径，PoC 验证和灰度切换都是必要的。
如需评估 MySQL 迁移方案，可免费试用平凯数据库或预约专家咨询。查看全行业解决方案了解不同行业的落地实践，或查看快速上手指南完成首次部署。