作者 | 云盛海宏 ToC 业务团队  崔文涛，邓有才

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

选型背景

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

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

分库分表不合理导致的数据倾斜，某个分片负载居高不下，且难以动态调整

a. 分库分表规则为品牌名称，而不同品牌之间数据规模、用户规模有较大差异

b. 需要针对大分片再次进行二次拆分才能解决该问题，但同时复杂度将大幅提升

个别单库架构的 MySQL，数据增长远超预期，单表数据量过大，性能问题凸显

a. 数据量千万级以上表：87 张；亿级以上表：21 张

b. 需要将单库架构改造成分库分表架构才能解决

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

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

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

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

数据库测试方案

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

迁移数据的完整性：数据是企业的核心资产，不容许丢失

SQL 兼容性及性能：这意味着我们迁移改造的成本

资源隔离能力：多个业务库合并后如何保障其服务质量

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

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

数据同步

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

数据比对

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

测试二：SQL 兼容性及性能

针对生产的全量 SQL 语句进行兼容性以及性能的测试，靠人力手工完成测试是不现实的，所以我们引入了 Percona 开源的 playback 工具进行测试。

playback SQL 回放工具经验分享

playback 工具介绍

项目地址：https://github.com/Percona-Lab/query-playback.git

SQL 录制：MySQL 数据库在开启慢查询功能时，会将慢 SQL 输出到慢查询日志

SQL 回放：playback 工具解析慢查询文件中的 SQL，并连接到目标数据库进行回放

报告展示： 回放完成会输出报告（执行失败的 SQL 含结果不一致等、性能数据）

实际测试流程

由于我们是存在分库分表架构，而 TiDB 中存储的都是单表，所以我们步骤进行了一些调整：

SQL 录制：将生产 MySQL 库的 long_query_time 设置为 0，运行一个业务周期（一天），记录一天内所有 SQL（样本数越大测试结果越准确）

SQL 处理：部分慢查询日志未记录 schema 信息，通过脚本指定 schema（还存在将 db_1 映射成 db 这样的 schema 转换）

SQL 回放： 指定慢查询回放整个业务周期运行的 SQL 语句

回放结果分析

测试结果汇总

由于私域商城大表十分多，所以性能提升非常明显，2524 万条 SQL 的总执行时间约之前的 1/6；而会员运营之前进行过拆分，737 万条 SQL 的执行总时间约之前的 1/2。

错误详情分析：

无业务 SQL 错误，业务 SQL 均兼容

所有错误均为非业务 SQL：如 MySQL 中"show binary logs/status/events"、set 特有变量、系统表查询，或慢查询格式调整时出现的一些格式错误等

1 处业务 SQL 错误：“during query: Data too long for column”，原因字段精度不够，调大后解决，其余业务 SQL 均兼容

剩余 1220855 次均为非业务 SQL 的报错：如 MySQL 中"show binary logs/status/events"、set 特有变量、系统表查询，或慢查询格式调整时出现的一些格式错误等

会员运营：

私域商城：

兼容性基本没有问题

性能详情分析：

虽然总体执行时间缩短了，但我们还是需要排查下性能退化的 SQL 是哪些，需要保证原本正常的 SQL 还是要处于在一个基本对用户无感知的响应时间范围。

理论上来说，小于 100ms 的 SQL 基本都不影响前端用户的体验，所以分析时可以忽略这一部分的 SQL；而对于 100ms-1s 的 SQL，可能会影响用户体验，需要关注；1 秒以上 时基本上用户感知非常明显。

通过详细性能分析数据以及 SQL 回放执行总耗时，我们不难发现：

1. 由于 TiDB 是存储计算分离的分布式架构，1000us 内的 SQL 数很少，基础操作（如 show variables/start transaction/set ... 等）执行时间均高于 MySQL；同时另一个极端，大于 10 秒以上的 SQL 数，两个系统在 TiDB 中下降了一个数量级。

2. 通过一些采样分析，我们发现在 TiDB 中一些 commit/rollback 操作的时间也普遍高于 MySQL，个别操作从几百微秒变成几十 / 几百毫秒。查阅了 TiDB 中的事务机制，发现 TiDB 提交成本高于 MySQL，首先是 2PC 跨节点事务，另外就是事务中的脏数据直到 commit 时才开始刷到存储（计算节点 ->存储节点），对于这种类型的 SQL 在性能分析时也可以忽略掉。

3. 我们将样本数据整理成桑基图，将这部分性能退化、并且影响用户体验的 SQL 识别出来，进行分析和优化

以上为会员运营中 SQL 性能数据桑基图，如红色箭头以及红色框的这些 SQL，需要重点分析

以上为会员运营中原本 10 秒以上 SQL 性能变化

4. 私域商城的 SQL 性能提升很明显，100ms 内 SQL 数量均高于 MySQL，同时 1s 以上的 SQL 少于 MySQL，说明用户体验提升明显。但还是需要根据桑基图来分析是否存在异常的 SQL

以上为私域商城系统 SQL 性能桑基图，红框对应的 SQL 应该重点分析

以上为私域商城原本 10 秒以上 SQL 性能变化

测试三：资源隔离能力

资源隔离能力在我们这边的用途：

应用监控等定时调度操作往往比较复杂，如何限制其运行时的资源消耗

客户端数据查询场景难以避免 SQL 条件不规范的情况，当出现这种情况时，如何避免人工查询导致的系统不可用

当某个系统中出现一个大查询时，如何限制其资源消耗，避免对该应用、对整个集群造成影响

当某个系统中批量调度作业到白天还没跑完时，如何限制其资源消耗，避免对白天业务造成影响

系统间资源隔离：多个 MySQL 库上的应用系统合并到一个 TiDB 时，如何保障各个系统在业务高峰期的可用资源

系统内资源隔离：

其他场景的资源隔离

为解决以上几种问题，需要使用 TiDB 7.1 LTS 提供的 Resource Control 功能，该功能能够实现：

按用户设置资源规格

按会话设置资源规格

按 SQL 设置资源规格

以下是用户级别测试效果：

为数据库压测用户指定其 RU 为 500，并使用 Jmeter 压测应用，观察 TiDB 数据库是否能够限制资源，并且在达到资源限制时，应用是否报错。

该用户在达到 500RU 时，使用值轻微超过限制值，基本符合预期。

应用改造

分页 SQL 增加排序条件

这也是几乎所有的 MySQL 系统迁移到 TiDB 会遇到的问题：

当SQL 中无显示排序条件时，返回结果无顺序保障，这将导致分页结果不可靠

我们大概梳理了系统中存在的分页 SQL，大概 1600 余条，最终改造 + 测试工作量约 2 个月

性能退化的 SQL 优化

如特定的表关联方式，执行计划是全表扫描

改写成

从分库分表处理逻辑改成单库处理逻辑

业务 sql 中存在批量查询、批量更新的场景，调整成按照用户链接维度设置 batchquery

数据回写改造

应用切换到 TiDB 前，需要将 TiDB 的增量数据写回到 MySQL，保障紧急情况下的可回退：

之前是单库的场景，可以直接使用 TiCDC 提供的 mysql sink 完成回写。

分库分表的场景下，TiCDC 并不能直接写 MyCAT 组件；所以我们先将增量数据通过 TiCDC 发送给 Kafka，再消费写入到 MyCAT 下的分片中。

下游订阅改造

TiDB 不兼容 MySQL Binlog，原本的消息订阅链路（Binlog/canal/kafka）需要换成 TiCDC->Kafka 这条链路，TiCDC 提供 canal-json 格式的兼容，消费程序上要基于 TiCDC 的消息格式进行一定的调整。

生产切换效果

我们于双十一之前的两周完成消息中心等系统（4 个 MySQL 库）的切换，切换到 TiDB 后经受住了双十一大批量消息推送的验证，也增强了我们的信心。

在元旦后第一个工作日进行了私域商城系统（16 个 MySQL 库）的切换，切换过程比较顺利。以下是切换后第一个工作日的业务高峰，最大 QPS 4.4 万，P95 响应延迟 3.9ms，整体运行良好。

1.8 日某品牌大促，业务量是平时的一倍，数据库最大 QPS 6.5 万，P95 响应延迟 3.9-4.5ms 之间：

以下是切换 TiDB 的整体流程，可以看到切换到 TiDB 后了简化了其架构：由于 TiDB 无需设置分片规则，数据都在一个集群中，原本综合库（MySQL 单库）上的查询也直接切到 TiDB

以上为生产切换流程

总结

数据库迁移是一个复杂且高风险的工程，迁移前规划一个全面的测试方案必不可少，提前识别迁移风险，大幅降低迁移后的风险，当然像分阶段迁移、回退链路等保障措施也及其重要。

年后我们将继续把会员运营系统（20 个 MySQL 库）切换至 TiDB，实现 To C 系统从 MySQL 40 个库到 TiDB 的整体切换，支撑未来持续增长的数据规模。