MySQL 到 TiDB 迁移实践：云盛海宏零售业海量场景下 ToC 系统的选型思考与经验分享

云盛海宏是一家零售业科技公司，以科技的力量为门店和线上客户打造 360 度的优秀体验，目前服务中国 6000 余家的线下门店和千万级别的线上会员。云盛海宏的 To C 系统分为私域商城和会员营销两条业务线，它为 7000 多万注册会员提供了丰富的权益和服务，是我们非常核心的系统。

选型背景

随着近几年消费模式的升级，我们和消费者的互动与服务从传统线下逐渐延展至线上，使得 To C 系统的能力和规模越来越大，其数据库压力也越来越大。

最初在建设 To C 系统时，业务库主要使用 MySQL，既有单库架构，也有分库分表架构，时至今日我们面临的问题主要如下：

1. 分库分表不合理导致的数据倾斜，某个分片负载居高不下，且难以动态调整
   ● 分库分表规则为品牌名称，而不同品牌之间数据规模、用户规模有较大差异
   ● 需要针对大分片再次进行二次拆分才能解决该问题，但同时复杂度将大幅提升
2. 个别单库架构的 MySQL，数据增长远超预期，单表数据量过大，性能问题凸显
   ● 数据量千万级以上表：87 张；亿级以上表：21 张
   ● 需要将单库架构改造成分库分表架构才能解决

以上两个问题均需要大幅调整数据库架构来解决，解决成本高（人力、硬件），并且未来还可能再次面临这样的问题。为彻底解决以上问题，我们计划直接切换到原生分布式数据库 TiDB：

1. TiDB 兼容 MySQL 协议，并且是原生分布式，无需规划分片规则，对应用友好，能够很好的解决之前分库分表数据倾斜的问题

2. TiDB 架构下提供的动态水平扩展、热点自动调度等能力，大幅简化了一系列运维成本，能够支撑应用规模持续的增长，即使数据增长超过预期也能动态增加节点解决

3. 另外我们的零售系统在去年成功切换到 TiDB，也给了我们团队很大的信心

数据库测试方案

对于数据库的切换我们比较关心以下几个问题：

1. 迁移数据的完整性：数据是企业的核心资产，不容许丢失
2. SQL 兼容性及性能：这意味着我们迁移改造的成本
3. 资源隔离能力：多个业务库合并后如何保障其服务质量

测试目的：识别关键问题，基于测试结果完善应用改造

测试一：迁移数据的完整性

1.1 数据同步

TiDB 提供 DM 数据同步工具，该工具支持 MySQL 全量、增量数据的同步，同时也支持分库分表的合并。对于分库分表的合并，我们的任务策略如下：

1.2 数据比对

为确保 DM 数据同步工具的可靠性，在切换过程中需要进行数据一致性校验。实测数据比对效率较高，能够达到 400MB/s 以上的全量比对速度，以下是数据比对映射关系：