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

数据运维 2024-02-06 大白菜程序猿手机阅读

本文来自 InfoQ，作者云盛海宏 ToC 业务团队崔文涛、邓有才。

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

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

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

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

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

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

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

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

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

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

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

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

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

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