1. 前语

得物 App 从创立之初，联系型数据库一贯运用的开源数据库产品 MySQL。和绝大部分互联网公司相同，跟着业务高速添加、数据量逐渐增多，单实例、单库、单表呈现功用瓶颈和存储瓶颈。从选型和架构规划视点来看这很符合开展规律，一开端没必要引进过于杂乱的架构导致资源本钱和开发本钱过高，而是逐渐跟着业务开展速度去迭代架构。为了应对这些问题，咱们采取了诸多办法如单库按业务逻辑拆分成多个库的笔直拆分，分库分表的水平拆分、一主多从读写别离等。这些技改一起也使得整个业务层架构更加杂乱，且无法做到通明的弹性，因此咱们逐渐把目光转向了现已趋于老练的分布式联系型数据库 TiDB。

自 2020 年头开端运用 TiDB，跟着运维体系的逐渐完善，产品本身才干的逐渐提高，接入业务现已触及得物的多个 业务线，其间个别为要害业务场景。业界关于 TiDB 的功用剖析、场景落地、渠道化建设都有许多优异的文章。本文依据得物内部的实践状况，会从选型战略、运维手法、运营方法、中心场景实践等几个方向讲述TiDB 在得物实践落地过程。

2. TiDB 架构

上图是咱们现在的接入方法和整体架构。TiDB 的布置架构这儿就不做赘述了，需求了解的同学能够参阅官方文档。咱们之所以选用 SLB 来做 TiDB 的负载均衡接入，便是为了简化接入本钱与运维本钱，拜访流量的负载均衡以及节点扩缩容能够经过调整 SLB 处理。当然假如能够完结 SDK 负载均衡与毛病除掉，结合装备中心的流量调度也是十分好的处理计划。得物 TiDB 布置均选用单机单实例布置，TiDB Server、PD 选用无本地 SSD 机型，TiKV 选用本地 SSD 机型。既统筹了功用，又能下降本钱。详细的机型挑选会在后边的内容说到。

3. MySQL 与 TiDB 的比照

圈内一贯流传着一句话，没有一种数据库是”银弹”。绝大部分用户挑选 TiDB 便是为了弥补 MySQL 的不足，所以选型阶段对两者做些比较也是在所难免的。本文依据咱们内部的现状和场景对两个产品咱们重视的点进行了简要比照。比照的意图不是为了去印证那个数据库产品才干更强。而是想经过比照来协助团队在适宜的场景挑选适宜的产品。

• 扩展性

  • MySQL

  MySQL 就本身扩展才干而言首要是来自于笔直扩容，可是这个会受限于机器的标准上限。水平扩容触及业务改造和运用本钱提高。改造为分库分表，对研制来说是一个费力度很高的计划。需求引进 Sharding 逻辑，改造完结后需求业务 SQL 必须带 Sharding Key 才干履行或许高效履行。所以并不是说做不到可扩展。

  • TiDB

  由于 TiDB 是核算存储别离的架构，且有状况的存储层 TiKV 是分布式存储。所以单从上面界说的扩展性来说，的确比照 MySQL 有很大优势。集群处理才干和存储才干，能够经过扩容 TiDB Server、TiKV 简略完结。这儿需求注意的是，TiKV 属于有状况服务，扩容会触及到数据的 Reblance，过程中 TiKV(region 搬迁) 和 PD(调度) 产生许多交互，为防止影响业务，扩缩容过程中需求重视集群状况，依据需求适当调整搬迁力度。

• 功用

  • MySQL

  关于 RT。MySQL 由于是单机数据库，所以关于点查或简略查询的 RT、热门更新的 RT 与 TPS ，比较分布式数据库有天然优势。数据获取链路短(单机数据库本地调用，分布式数据库触及存算别离)，且不必考虑分布式业务的抵触检测。所以整体的拜访 RT 要低于 TiDB，详细数据这边就不罗列了，社区有不少功用压测的帖子。

  关于聚合查询。互联网公司在 C 端基本不存在此类问题，也是不答应的。所以首要是场景在 B 端。处理方法一般是分为几种：1.供给专门的只读实例给 B 端供给查询才干；2.异构数据来处理（MySQL+ES、ADB 等等）。

  关于优化器。MySQL 多年的堆集，在优化器的安稳性尽管不如商用数据库那么牢靠，偶然也有走错索引的状况。一般只能经过修正 SQL、修正索引来处理，牢记别用 force index 这种有坑的处理计划。可是整体来说咱们遇到的 MySQL 走错索引的状况要远低于 TiDB。

  • TiDB

  关于 RT。分布式数据库处理的更多是吞吐量和容量上的需求，比方点查或简略查询的 RT 无法像单机数据库那么短，可是能够经过节点扩容的方法提高 QPS 吞吐量。热门数据这儿就不打开讲了，它本身也不是分布式数据库能处理的范畴。假如你的业务场景是一个对 RT 要求很高的场景，那么优先运用 MySQL。假如是高吞吐量需求优先，能够尝试运用 TiDB。

  关于聚合查询。由于 TiDB 的存储节点 TiKV 不仅仅具有存储才干，TiKV 完结了coprocessor 结构来支撑分布式核算的才干。所以理论上经过加机器就能扩展核算才干，从咱们实际运用的场景来看也是如此，这部分的才干就要优于 MySQL。详细的作用在本文最后的章节会有体现。

  关于优化器。这个是咱们对 TiDB 一贯以来吐槽的点之一，有时分计算信息健康度 90 以上的状况下，仍是会走错索引，当然这儿有一部分原因可能是条件过多和索引过多导致的。为了处理问题，中心服务上线的 SQL 就必须逐个 Review。假如无法正确运用索引的就运用 SPM 绑定，尽管能处理，可是运用本钱仍是略高。期望官方继续加油。

• 资源本钱

  • MySQL

  假如是一个数据量小且查询模型比较简略的需求(比方：1-2TB，简略查询为主)，那么肯定是 MySQL 本钱较低。以咱们 TiDB 根底装备为例，比较 MySQL 本钱高出 27%(该本钱是用高可用的 MySQL 对标3 TiDB、3 TiKV、3 PD 的 TiDB)。所以得物内部选型，单从资源本钱视点考虑，仍是首选 MySQL。

  TiDB假如是一个数据量较大且持续添加或查询模型比较杂乱的需求(比方：3-5 TB 以上，多条件查询、聚合查询等)。一般该类型的业务都选用分库分表的处理计划。以得物一个分库分表的集群(10个写实例、10个读实例)为例，替换为 TiDB(6 TiDB、12 TiKV、3 PD)，本钱比较 MySQL 本钱节约 58%。此比方只作为得物一个业务场景的替换效果，不代表一切场景。为了验证这个定论，本文后边的内容会讲到这个中心场景的实践。

• 运维本钱

  • MySQL

  MySQL 作为被运用最多的开源联系型数据库，从社区活跃度、产品老练度、周边生态东西、处理计划堆集等方面来看都是十分优先的产品。主从架构的 MySQL 保护本钱极低，当主库异常或无法修复时，咱们只需求切换即可。

  别的得益于优异的社区生态，运维东西、数据库接入组件、数据同步组件都有十分多的老练东西，稍加改造就能够完本钱地化适配。

  • TiDB

  分布式的架构的规划没有像 MySQL 这样的主从，每个存储节点都是供给读写。当一个节点出问题的时分，会影响整个集群的拜访。无法完结 MySQL 这样经过主从切换完结快速的毛病阻隔。

  TiDB 由 3 个角色组成，当呈现问题的时分无法快速定位问题(当然也是咱们个人才干需求提高的点)，比方当某个时刻点的查询超过预期的时分，需求排查履行计划、各个节点的负载状况、各节点的网络状况。尽管供给了完善的监控，可是目标与节点过多需求逐个排查才干有定论。不像 MySQL 呈现查询超预期的问题，基本上经过几个中心目标就能判别出根因。

• 结构改变(DDL)

  • MySQL

  这儿以咱们首要运用的 MySQL 5.7 为例，较大数据量的状况下 DDL 本钱较高，为了躲避锁表和主从推迟的问题，一般都是用东西去履行。咱们通常运用的两个知名开源无锁 DDL 东西：Percona 开源的 pt-osc、Github 开源的 gh-ost。现在咱们和大部分公司相同都在经过定制化开发的 gh-ost 来改变。可是用东西仅仅处理了前面说到的锁表和主从推迟问题，跟着数据量规划上升，改变时长也逐渐上升。别的东西的 Bug 也会带来数据丢掉的危险。当然 MySQL 8.0 的特性 Instant Add Column 推出今后处理了加列的痛点，可是也只处理了一部分。

  • TiDB

  TiDB 的 DDL 经过完结 Google F1 的在线异步 schema 改变算法，来完结在分布式场景下的无锁，在线 schema 改变。DDL 改变中除过 add index 以外其他都不需求做数据回填，修正完元信息即可，所以能够立即完结。而 add index 会做两件作业：1.修正 table 的元信息，把 indexInfo加入到 table 的元信息中去；2.把 table 中已有了的数据行，把 index columns的值悉数回填到 index record中去。改变速度取决于表中的数据和体系负载。所以 TiDB 在 DDL 操作上处理了许多 MySQL 上的痛点，可是与 MySQL 比较，TiDB 的 DDL 仍是有些不相同的当地的，也带来了一些约束：

  1. 不能在单条 ALTER TABLE 语句中完结多个操作。MySQL 下会把多个同一张表的 DDL 进行兼并，然后运用 gh-ost 或许 pt-osc 东西一次性履行。TiDB 里只能一个个独自去履行；(6.2 现已支撑了ALTER TABLE语句增修正多个列或索引)
  2. 不支撑不同类型的索引 (HASH|BTREE|RTREE|FULLTEXT)；
  3. 不支撑添加 / 删除主键，除非开启了 alter-primary-key 装备项；
  4. 不支撑将字段类型修正为其超集，例如不支撑从 INTEGER 修正为 VARCHAR，或许从 TIMESTAMP 修正为 DATETIME，否则可能输出的过错信息 Unsupported modify column
  5. 更改 / 修正数据类型时，尚未支撑“有损更改”，例如不支撑从 BIGINT 更改为 INT;
  6. 更改 / 修正 DECIMAL 类型时，不支撑更改精度 ;
  7. 更改 / 修正整数列时，不答应更改 UNSIGNED 属性 ;

这儿大部分约束能够在结构规划阶段和后期规范来躲避掉，比方一个表的多个 DDL 操作无法兼并的问题，能够经过自动化手法下降杂乱度；BIGINT 更改为 INT 这种长改短的便是日常改变规范中要管控的。

• 产品流行度

  • MySQL

  假如咱们从 MySQL 1.0 开端算起至今现已有 26 年了。这期间几经周转，终究归到了 Oracle 旗下。版别也从 1.0 来到了 8.0。作为一个久经锻炼的数据，特别是作为互联网盛行时期依靠的主流数据库，不论是产品老练度和社区活跃度都得到了极大的促进。MySQL 在 DB-Engines 的开源数据库中排名久居第一。

图片数据来历DB-engines 官网

• • TiDB

  TiDB 从 2015 年创立并开源至今现已 7 年，作为一个杂乱的根底软件来说的确还比较年青。依靠前期的 3 个创始人互联网布景出身，深知咱们在联系型数据库上的痛点。所以 TiDB 推出后获得了不少用户的推崇，特别是互联网职业。社区在 TiDB 的开展中也起到了至关重要的作用，从打磨产品、需求提炼、落地场景总结等。现在 TiDB 在 DB-Engines 排名为 98，进一步证明晰根底软件的难度以及作为一款国产数据库在国际化进程中还有很大的空间。从墨天轮中国数据库排行的状况，能够看到 TiDB 长时间以来保持第一的位置。在 12 月下跌第一，由 OceanBase 替代。

图片数据来历 墨天轮

4. TiDB 在得物的运维体系落地及探索

4.1 选型

关于数据库选型，咱们一贯十分慎重，会依据详细的业务状况来引荐适宜的数据库。要防止陷入“手拿铁锤的人,看什么都像钉子”的误区。不是为了运用 TiDB 而运用，要去处理一些 MySQL 无法满意或许改造本钱比较高的场景。联系型数据库咱们仍是优先引荐MySQL。能用分库分表能处理的问题尽量挑选 MySQL。毕竟运维本钱相对较低、数据库版别更加安稳、单点查询速度更快、单机QPS功用更高这些特性是分布式数据库无法满意的。以下是咱们总结的关于选型的两个大方向。

适宜接入的场景：

• 分库分表场景:上游 MySQL 分库分表，业务查询时无法运用到分片
• 磁盘运用大场景: CPU 和内存运用率低但磁盘容量达到 MySQL 瓶颈
• 剖析 SQL 多场景:业务逻辑比较杂乱，存在并发查询+剖析查询
• 数据归档场景:数据冷热别离、定期归档、数据重要，不能丢掉
• 日志流水场景:日志流水业务、单表较大、写入平稳、查询不多

不适宜接入的场景：

• 数据抽取场景:下流存在大数据或许其他业务部门进行数据抽取
• 读写别离的场景: TIDB 没有主从的概念，无法进行读写别离
• 指定点康复场景:指定时刻点等级康复，需求康复到某个时刻点
• 数据热门场景:高并发单行更新、热门小表、热门库存

4.2 运维标准化

• 业务接入

场景：当业务选型考虑TiDB时，咱们会依据业务的运用场景和业务特点归纳评价是否适宜TiDB(优先 引荐运用MySQL)。

装备：评价业务本钱压力和未来一年数据量、TPS，挑选适宜的TiDB集群装备。

运用：给运用方供给 MySQL 和 TiDB 的差异及其规范，防止添加开发周期和本钱。

• 资源标准

依据不同业务场景，咱们界说了不同的服务器装备。由于借助云上的资源交付才干和阻隔才干， 咱们无需像 IDC 那样，在高标准机器上选用多实例布置。这样防止了混部带来两个问题：1.多个实例之间的资源争夺；2.高规则机器布置密度与安稳性的权衡。

节点	数量	装备
TIDB	3	根底标准：8C32G200GB(云盘)高配标准：16C64G200GB(云盘)
PD	3	根底标准：8C16G200GB(云盘)高配标准：16C64G200G(云盘)
Monitor	1	4C16G200GB(云盘)
TIKV/TIFLASH	3	根底标准：8C32G1788G(本地SSD)高配标准：16C64G1788G(本地SSD)

• 数据库备份

备份东西：BR[官方物理备份东西]

备份战略：凌晨低峰期进行数据全量备份

备份保存周期：7天

• • 在线业务

关于在线业务，除了惯例的BR备份外会额定调整 tikv_gc_life_time 时刻为 1-3 天，当业务呈现误操作时能够康复三天内任意时刻的数据。

• • 离线业务

TiDB集群离线业务大部分是从上游RDS同步到TiDB的场景。上游RDS会有一份最近的数据，所以关于离线业务只要惯例的BR备份。

4.3 安稳性办理

• 改变办理
  • 面向 DBA 的流程管控

上图的流程首要是用于管控非白屏化的 TiDB 根底设施改变。经过改变文档整理、运维小组 Review 的机制，保证杂乱改变的规范化。

• • 面向研制改变的体系管控DML\DDL 改变工单危险自动化辨认

语法查看：

1. DDL 与 DML 类型判别，保证每次履行的内容是同一个类型
2. SQL 语法查看，保证提交的 SQL 语法是正确的

合规查看：

改变合规性查看，保证提交的 SQL 是能够按照 DBA 界说的规范规划(能够运用的字段类型、字段命名、索引命名、索引数量，字段长度由长修正短等约束)，简略说便是要么答应，要么不答应

危险辨认：

1. 该项的作用是将答应履行的进行危险辨认，研制能够依据危险等级挑选履行时刻，DBA 也能在批阅阶段判别是否合理，并修正履行时刻。

2. 相关危险界说

下图是依据以上说到的才干，完结的 TiDB 改变管控功用。

• 安稳性巡检

数据库巡检手法是相当于告警比较前置的一个动作，巡检阈值比较告警较低，意图是为了提早发现问题并跟进处理。收益是：1.下降告警数量；2.防止小问题逐渐堆集导致大问题。咱们的做法是按照自界说的评分规则，双日晨会对焦，对有危险的服务进行问题跟进。

巡检目标的数据收集来自于监控体系，咱们会计算相关目标的峰值。每天记载一个点，展示近 30 天内的目标值。

某集群的巡检状况

• 慢查办理

尽管 TiDB 自带的 Dashboard 能够供给慢查的白屏化，可是这需求供给账号密码给研制，5.0 之前的版别还必须运用 root 账号登录，别的便是咱们期望慢查办理能够结合内部体系进行办理。所以关于这部分做了些自研作业，将日志收集并加工后存入 ES。DBA 渠道能够经过报表等手法进行推动办理。

下面两张图便是咱们内部的渠道对慢查办理的闭环办理计划。DBA 或许研制 TL 在渠道指派 SQL，处理人就会收到办理音讯，处理完结后能够在后台进行状况改变。然后依据这些数据能够做报表优化办理作用。

• 告警办理

依据 TiDB 官方的监控计划，咱们在告警部分做了些定制化，Prometheus 中装备的 rule 触发后会把告警信息推送至咱们自己的数据库办理渠道 OneDBA，由渠道处理后进行发送。渠道的告警办理模块的完结类似于 Alertmanager，不同的咱们新增了自界说的需求，比方元信息关联、支撑集群目标等级的阈值界说、告警沉默、告警降噪、告警办理闭环(有告警告诉和招领，保证及时跟进处理)。别的这儿的 Prometheus 首要功用是做数据收集与告警，数据存储与趋势图查看在公司统一监控渠道，下降不必要的存储资源投入。由于咱们办理的数据库类型比较多，所以在告警计划上做了收敛。这儿讲到的计划便是得物数据库团队现在针对担任的一切数据库的办理计划。

阈值办理

• 毛病演练

毛病演练的意图是为了巩固现在的体系高可用。咱们针对 TiDB 拟定了一套成心演练流程，包括了 8 个场景。

【演练场景1】TiKV Server 1 个节点宕机

【演练场景2】TiDB Server 1 个节点宕机

【演练场景3】PD Server 1 个节点宕机

【演练场景4】PD Server 节点重启

【演练场景5】TiKV Server 节点重启

【演练场景6】运用高并发写入，CPU、IO告警是否及时发送

【演练场景7】PD Server Leader、follow节点重启

【演练场景8】TiDB 集群 宕机一个TiDB Server节点

以上的场景咱们经过 ChaosBlade 完结了 100% 自动化毛病注入。毛病演练也促进咱们达到整个技能部的目标：1 分钟发现，5 分钟止损，10 分钟定位。现在也正在计划将该流程引进新集群交付前以及版别晋级后的标准化流程。

4.4 人才储藏

• 专业认证

PingCAP 现在有三个认证，别离是 PCTA、PCTP、PCSD。前两个是前期推出面向 DBA 从业者岗位初高档认证。得物 DBA 团队有 6 位同学获得TiDB的 PCTA 认证考试、其间 5 位同学获得了进阶的 PCTP (TiDB专家)认证考试。认证尽管不能彻底代表实力，可是代表了 DBA 团队对技能的追求和 DBA 团队在得物做好 TiDB 服务支撑的决计与态度。

经过PCTP认证学习，团队成员深化了解TiDB数据库的体系架构、规划理念与各个组件的运行原理。学习并掌握 TiDB 数据库的体系架构，规划实践，功用监控、参数优化、毛病扫除、SQL优化和高可用规划。这个关于公司和团队来说便是人才和技能上的储藏。

部分在职的 PCTP 得物 DBA 证书截图

• 运维小组

对自建数据库服务咱们选用了小组担任制，以 TiDB 为例，会有 3 名同学担任根底设施运维的作业(资源评价、改变流程评价、二线问题处理等)，其间一名是 Owner。关于日常业务侧的改变、SQL 优化等由详细对接业务的 DBA 担任处理。这样既处理了人员互备问题，又处理了改变危险评价问题，还处理了运维小组运维压力的问题。

4.5 技能运营

关于一个新式数据库，DBA 依据产品特性介绍、场景剖析、案例共享等，在公司内部的技能运营也十分重要。它决定了研制同学对这个产品的认知和信心。好的技能气氛必定是得益于公司内部完善的机制和渠道，一起你也能合理的加以运用。这儿没有讲到对外共享，是由于咱们的原则是先内部沉积修炼，然后再对外共享。以下是咱们关于 TiDB 的技能运营在公司内部的 3 个主战场。

• 技能共享

技能夜校是得物技能部技能文明的特征之一。为技能部有意共享的同学供给一个渠道，就现有技能实战经历、技能研究效果、重点项目回忆等，在技能部与同学们做共享和沟通，营建浓厚的技能共享气氛，构成技能知识沉积，打造学习型安排，提高技能影响力，拓宽技能同学的知识面。

这是一个能够有力促进技能影响力和产品影响力的机会，咱们当然也不能错过。本文的作者在刚入职得物的时分就共享了《分布式数据库 TiDB 的规划和架构》，培训教室座无虚席，参加人次创下新高。这次共享让研制对 TiDB 也有了一个全面的认识。所以技能共享必定程度上处理了前面说的产品才干认知问题。

• 技能博客

“毒”家博客也是得物技能部技能文明的特征之一。初衷是为了各位同学们沟通技能心得，经过输入与输出的方法促进前进、彼此成长。许多高质量文章也被推送到了得物技能公众号。

DBA 团队借助内部的技能博客渠道，输出了多篇有关 TiDB 的技能文章。内容涵盖中心原理剖析、优化案例、毛病 case 剖析、业务场景落地等。在整个气氛的带动下，不少研制同学也发表了关于 TiDB 的学习和落地的技能文章。

• 课程录制

安排内部的技能共享的投入较大，共享的频次不宜太高，否则参加度也会比较低。而且从内容深度、知识获取效率、自助学习来看，共享也不是长时间的计划。录制视频课程的作业就提上日程了，视频课程的优点是能够浓缩知识点，将技能共享 40 分钟的内容(有一些不必要的内容，比方重复的话、口头语等)压缩至 15 分钟。完美处理了前面说到的问题。正好公司内部有一个自研的学习渠道，日常就用于发布各种培训、学习的视频。为保证录制作用和效率咱们前期的课程都预备了稿件。咱们依据这个渠道也发布了一期( 5 节)课程，最近现已在准备第二期的课程内容了。

课程录制也能够使 DBA 再一次复习细节知识，由于要讲清楚知识点，就必须自己深化了解。这个必定程度上表明晰咱们对 TiDB 的了解程度和做好它的决计，也给了研制运用的信心。

5. TiDB 在中心业务场景实践

5.1 业务痛点

得物商家订单库由前期 MySQL 单库进阶到 MySQL 分库分表，这个计划支撑了业务的高速开展。而以商家 ID 做 shareding-key，会使的同一个商家的订单数据都会在一个表中，跟着订单量的逐渐提高，终究大商家的查询会构成了单点功用问题。首要体现在慢 SQL 较多和 数据库负载上升，每天约 1W 条慢 SQL，部分计算类查询现已超 10S。别的便是单机容量也有上限，笔直扩容受限。跟着订单量的上升，体系整体的功用和容量需求最进一步的规划。

5.2 处理思路

依据以上说到的问题，咱们对一切的处理计划都做了比照。表格中是对四种处理计划的要害信息提炼。咱们期望能够挑选一个比较长时间的计划，能够支撑未来 3-5 年的需求，既要处理功用问题，还要处理容量问题，又要比较低的研制本钱。所以终究挑选了引进分布式数据库的计划。

5.3 数据库选型

依据现在得物在运用的数据库进行了评价，首要包括以下三种挑选。

由于得物在 2020 年就引进了 TiDB。尽管没有大规划推行，可是陆续也有不少业务接入。大部分的业务把它作为 MySQL 分库分表的聚合库运用，有一小部分业务是直接接入了读写需求。依据之前的实践经历和业务需求，经过和研制团队的洽谈，直接选用的读写库的运用计划。别的一个方面是从只读过渡到全量读写的周期会比较长，会产生不必要的并行本钱和推迟项目时刻。

5.4 兼容性&功用测验

• 兼容性测验

SQL 兼容性的问题，咱们并没有彻底依靠后期的业务测验来验证。而是经过获取 MySQL 上的全量 SQL 的方法进行验证。由于咱们将全量 SQL 存储在了 Clickhouse，而且存储前做了SQL 指纹提取。所以很简单能够获得去重后的业务 SQL。然后将一切类型的 SQL 样本在 TiDB 中进行回放，这儿首要针对 Select。终究测验一切业务 SQL 100% 兼容。

SQL 指纹

• 功用测验
  • 单量较少的商家场景功用测验

和预期的效果相同，由于 TiDB 分布式的架构，数据获取路径比 MySQL 要长，所以 RT 上比较 MySQL 别离多出 91%、76%、52%。从这儿能够看出跟着并发的上升，TiDB 和 MySQL 之间的 RT 距离也逐渐缩短。由于 TiDB 能够经过扩展 DB 和 KV 节点提高 QPS 才干，咱们在压测中也做了相关验证，符合预期。包括现有数据量翻一倍的根底上对功用的影响也做了验证，定论是无影响。为了便利和后边的内容比照，咱们这儿只供给了 RT 的目标。

• • 单量较多的商家场景功用测验

咱们挑了几个呈现频率较高且查询较慢的 SQL进行测验，概况参照以下内容。

SQL1

SELECT *
  FROM table_name
 WHERE xx_id= 1203030
   AND xx_status IN(4000, 3040)
   AND is_del= 0 ORDER BY id DESC,
         create_time DESC  LIMIT 20

SQL2

SELECT [column_name] FROM table_name
WHERE xx_id = 1203030
        AND xx_status = 8010
        AND close_type = 13
        AND close_time > ‘2022-06-19 18:16:24.519'
LIMIT 0, 30000

SQL3

SELECT * FROM table_name
 WHERE xx_id= 1203030
   AND xx_status IN(7000, 8000, 8010)
   AND is_del= 0
ORDER BY id DESC,create_time DESC 
LIMIT 20

SQL4

select count(*)  from table_name
 WHERE(seller_id= 1203030
   and is_del= 0
   and biz_type in('0', '12')
   and create_time>= '2021-11-01 00:00:00.0'
   and create_time< '2021-11-30 23:59:59.0'
   and(xx_status<> 1000 R biz_type<> 21))

关于 xxDB 特别做了处理，咱们能够疏忽，由于咱们首要比照的是 MySQL 和 TiDB。从测验效果来看作用很好，彻底满意业务侧的要求。

5.5 遇到的一些问题

• SQL 履行计划

问题：

首先阐明一下，计算信息健康度是 90 以上。SQL 仍是会选错索引。咱们剖析了一下，首要是两个问题：1.查询条件比较多，索引也比较多；2.优化器的才干待提高。

处理计划：

上线前和研制对已有 SQL 进行了全面的 Review，假如履行计划不对，就经过 SPM 处理。

• Bug

问题1：

Update 语句并发履行耗时 3S，经过排查是由于研制未运用显示业务，所以第一次履行是达观业务，第二次重试才是失望业务。调整今后遇到了失望业务下，偶发性的写写抵触的问题。经排查是由于失望锁未获取到导致的写写抵触，需求晋级到 5.3.2 才干处理。

处理计划：

晋级版别到 5.3.2 处理

问题 2：

TiDB呈现部分节点不可用，SQL履行报 Region is unavailable 过错。经排查是 5.3.2 引进的 TiKV bug。

PD leader 产生切换后，TiKV 向 PD client 发送心跳请求失败后不会重试，只能等候与 PD client 重连。

这样，毛病 TiKV 节点上的 Region 的信息会逐渐变旧，使得 TiDB 无法获取最新的 Region 信息，导致 SQL 履行犯错。

处理计划：

这是一个让人后背发凉的 bug。其时的判别是由于 PD 切换导致的，可是不清楚是 bug。咱们选用了影响最小的毛病康复计划(把 PD leader 切回去，由于原 PD Leader 没有挂，仅仅产生了切换)。问题处理后在官方发现了这个bug fix。所以又安排了晋级。

这是咱们上线过程中遇到的几个典型问题。整体来说引进一个新数据库就会带来必定的试错本钱，所以咱们仍然处于慎重选型的状况。别的便是吐槽一下，就上面的问题 2，主张官方要加强 Code Review 和混沌工程演练。

5.6 上线作用

• 功用收益

为了保证上线安稳性，咱们经过灰度切流的方法逐渐放量。彻底切流后效果明显，慢 SQL 几乎悉数消失，如下图所示。

• 本钱收益

由于 MySQL 的分库分表集群由 10个写实例、10个读实例构成，搬迁至 TiDB 后的集群规划为 TiDB6、TiKV12。本钱下降了58%。所以再重复说一下选对了场景，TiDB 也能顺带节约本钱。

• 大促考验

项目上线后轻松应对了本年的双 11、双 12，大促中的体系 RT表现安稳。

6. 总结

最后特别阐明下，文章中触及一些产品的比照仅仅依据咱们其时的场景和需求进行的剖析，并不代表某个数据库产品的好坏。写这篇文章的意图是想把咱们 TiDB 落地经历做个阶段性总结，趁便也能给同行们做个大方向上的参阅。咱们的这套方法论，理论上适用于任何一个需求再企业内部引进新型数据，而且推行的场景。本文触及的内容和方向比较多，无法每个模块都做深化的探讨。后边咱们也会把咱们感兴趣的模块独自拆分出来做几期深化共享。

*文/xiaoyu

重视得物技能，每周一三五晚18:30更新技能干货

要是觉得文章对你有协助的话，欢迎评论转发点赞～