如何构建企业内的TiDB自运维体系

　　前言
　　得物App从创立之初，关系型数据库一直使用的开源数据库产品MySQL。和绝大部分互联网公司一样，随着业务高速增长、数据量逐步增多，单实例、单库、单表出现性能瓶颈和存储瓶颈。从选型和架构设计角度来看这很符合发展规律，一开始没必要引入过于复杂的架构导致资源成本和开发成本过高，而是逐步随着业务发展速度去迭代架构。为了应对这些问题，我们采取了诸多措施如单库按业务逻辑拆分成多个库的垂直拆分，分库分表的水平拆分、一主多从读写分离等。这些技改同时也使得整个业务层架构更加复杂，且无法做到透明的弹性，因此我们逐步把目光转向了已经趋于成熟的分布式关系型数据库TiDB。
　　自2020年初开始使用TiDB，随着运维体系的逐步完善，产品自身能力的逐步提升，接入业务已经涉及得物的多个业务线，其中个别为关键业务场景。业界关于TiDB的功能剖析、场景落地、平台化建设都有很多优秀的文章。本文基于得物内部的实践情况，会从选型策略、运维手段、运营方式、核心场景实践等几个方向讲述TiDB在得物实践落地过程。
　　TiDB架构
　　上图是我们目前的接入方式和整体架构。TiDB的部署架构这里就不做赘述了，需要了解的同学可以参考官方文档。我们之所以采用SLB来做TiDB的负载均衡接入，就是为了简化接入成本与运维成本，访问流量的负载均衡以及节点扩缩容可以通过调整SLB解决。当然如果能够实现SDK负载均衡与故障剔除，结合配置中心的流量调度也是非常好的解决方案。得物TiDB部署均采用单机单实例部署，TiDBServer、PD采用无本地SSD机型，TiKV采用本地SSD机型。既兼顾了性能，又能降低成本。详细的机型选择会在后面的内容提到。
　　MySQL与TiDB的对比
　　圈内一直流传着一句话，没有一种数据库是银弹。绝大部分用户选择TiDB就是为了弥补MySQL的不足，所以选型阶段对两者做些比较也是在所难免的。本文基于我们内部的现状和场景对两个产品我们关注的点进行了简要对比。对比的目的不是为了去印证那个数据库产品能力更强。而是想通过对比来帮助团队在合适的场景选择合适的产品。扩展性MySQLMySQL就自身扩展能力而言主要是来自于垂直扩容，但是这个会受限于机器的规格上限。水平扩容涉及业务改造和使用成本提升。改造为分库分表，对研发来说是一个费力度很高的方案。需要引入Sharding逻辑，改造完成后需要业务SQL必须带ShardingKey才能执行或者高效执行。所以并不是说做不到可扩展。TiDB由于TiDB是计算存储分离的架构，且有状态的存储层TiKV是分布式存储。所以单从上面定义的扩展性来说，确实对比MySQL有很大优势。集群处理能力和存储能力，可以通过扩容TiDBServer、TiKV简单实现。这里需要注意的是，TiKV属于有状态服务，扩容会涉及到数据的Reblance，过程中TiKV（region迁移）和PD（调度）产生大量交互，为避免影响业务，扩缩容过程中需要关注集群情况，根据需求适当调整迁移力度。性能MySQL
　　关于RT。MySQL由于是单机数据库，所以对于点查或简单查询的RT、热点更新的RT与TPS，相比分布式数据库有天然优势。数据获取链路短（单机数据库本地调用，分布式数据库涉及存算分离），且不用考虑分布式事务的冲突检测。所以总体的访问RT要低于TiDB，具体数据这边就不罗列了，社区有不少性能压测的帖子。
　　关于聚合查询。互联网公司在C端基本不存在此类问题，也是不允许的。所以主要是场景在B端。解决方法一般是分为几种：1。提供专门的只读实例给B端提供查询能力；2。异构数据来解决（MySQLES、ADB等等）。
　　关于优化器。MySQL多年的积累，在优化器的稳定性虽然不如商用数据库那么可靠，偶尔也有走错索引的情况。一般只能通过修改SQL、修改索引来解决，切记别用forceindex这种有坑的解决方案。但是总体来说我们遇到的MySQL走错索引的情况要远低于TiDB。TiDB
　　关于RT。分布式数据库解决的更多是吞吐量和容量上的需求，比如点查或简单查询的RT无法像单机数据库那么短，但是可以通过节点扩容的方式提升QPS吞吐量。热点数据这里就不展开讲了，它本身也不是分布式数据库能解决的范畴。如果你的业务场景是一个对RT要求很高的场景，那么优先使用MySQL。如果是高吞吐量需求优先，可以尝试使用TiDB。
　　关于聚合查询。由于TiDB的存储节点TiKV不只是具备存储能力，TiKV实现了coprocessor框架来支持分布式计算的能力。所以理论上通过加机器就能扩展计算能力，从我们实际使用的场景来看也是如此，这部分的能力就要优于MySQL。具体的效果在本文最后的章节会有体现。
　　关于优化器。这个是大家对TiDB一直以来吐槽的点之一，有时候统计信息健康度90以上的情况下，还是会走错索引，当然这里有一部分原因可能是条件过多和索引过多导致的。为了解决问题，核心服务上线的SQL就必须一一Review。如果无法正确使用索引的就使用SPM绑定，虽然能解决，但是使用成本还是略高。希望官方继续加油。资源成本MySQL如果是一个数据量小且查询模型比较简单的需求（比如：12TB，简单查询为主），那么肯定是MySQL成本较低。以我们TiDB基础配置为例，相比MySQL成本高出27（该成本是用高可用的MySQL对标3TiDB、3TiKV、3PD的TiDB）。所以得物内部选型，单从资源成本角度考虑，还是首选MySQL。TiDB如果是一个数据量较大且持续增长或查询模型比较复杂的需求（比如：35TB以上，多条件查询、聚合查询等）。一般该类型的业务都采用分库分表的解决方案。以得物一个分库分表的集群（10个写实例、10个读实例）为例，替换为TiDB（6TiDB、12TiKV、3PD），成本相比MySQL成本节省58。此例子只作为得物一个业务场景的替换结果，不代表所有场景。为了验证这个结论，本文后面的内容会讲到这个核心场景的实践。运维成本MySQL
　　MySQL作为被使用最多的开源关系型数据库，从社区活跃度、产品成熟度、周边生态工具、解决方案积累等方面来看都是非常优先的产品。主从架构的MySQL维护成本极低，当主库异常或无法修复时，我们只需要切换即可。
　　另外得益于优秀的社区生态，运维工具、数据库接入组件、数据同步组件都有非常多的成熟工具，稍加改造就可以实现本地化适配。TiDB
　　分布式的架构的设计没有像MySQL这样的主从，每个存储节点都是提供读写。当一个节点出问题的时候，会影响整个集群的访问。无法实现MySQL这样通过主从切换实现快速的故障隔离。
　　TiDB由3个角色组成，当出现问题的时候无法快速定位问题（当然也是我们个人能力需要提升的点），比如当某个时间点的查询超过预期的时候，需要排查执行计划、各个节点的负载情况、各节点的网络情况。虽然提供了完善的监控，但是指标与节点过多需要一一排查才能有结论。不像MySQL出现查询超预期的问题，基本上通过几个核心指标就能判断出根因。结构变更（DDL）MySQL
　　这里以我们主要使用的MySQL5。7为例，较大数据量的情况下DDL成本较高，为了规避锁表和主从延迟的问题，一般都是用工具去执行。我们通常使用的两个知名开源无锁DDL工具：Percona开源的ptosc、Github开源的ghost。目前我们和大部分公司一样都在通过定制化开发的ghost来变更。但是用工具只是解决了前面提到的锁表和主从延迟问题，随着数据量规模上升，变更时长也逐步上升。另外工具的Bug也会带来数据丢失的风险。当然MySQL8。0的特性InstantAddColumn推出以后解决了加列的痛点，但是也只解决了一部分。TiDB
　　TiDB的DDL通过实现GoogleF1的在线异步schema变更算法，来完成在分布式场景下的无锁，在线schema变更。DDL变更中除过addindex以外其他都不需要做数据回填，修改完元信息即可，所以可以立即完成。而addindex会做两件事情：1。修改table的元信息，把indexInfo加入到table的元信息中去；2。把table中已有了的数据行，把indexcolumns的值全部回填到indexrecord中去。变更速度取决于表中的数据和系统负载。所以TiDB在DDL操作上解决了很多MySQL上的痛点，但是与MySQL相比，TiDB的DDL还是有些不一样的地方的，也带来了一些限制：不能在单条ALTERTABLE语句中完成多个操作。MySQL下会把多个同一张表的DDL进行合并，然后使用ghost或者ptosc工具一次性执行。TiDB里只能一个个单独去执行；（6。2已经支持了ALTERTABLE语句增删改多个列或索引）不支持不同类型的索引（HASHBTREERTREEFULLTEXT）；不支持添加删除主键，除非开启了alterprimarykey配置项；不支持将字段类型修改为其超集，例如不支持从INTEGER修改为VARCHAR，或者从TIMESTAMP修改为DATETIME，否则可能输出的错误信息Unsupportedmodifycolumn更改修改数据类型时，尚未支持有损更改，例如不支持从BIGINT更改为INT；更改修改DECIMAL类型时，不支持更改精度；更改修改整数列时，不允许更改UNSIGNED属性；
　　这里大部分限制可以在结构设计阶段和后期规范来规避掉，比如一个表的多个DDL操作无法合并的问题，可以通过自动化手段降低复杂度；BIGINT更改为INT这种长改短的就是日常变更规范中要管控的。产品流行度MySQL
　　如果我们从MySQL1。0开始算起至今已经有26年了。这期间几经周转，最终归到了Oracle旗下。版本也从1。0来到了8。0。作为一个久经锤炼的数据，特别是作为互联网盛行时期依赖的主流数据库，不论是产品成熟度和社区活跃度都得到了极大的促进。MySQL在DBEngines的开源数据库中排名久居第一。
　　图片数据来源DBengines官网TiDB
　　TiDB从2015年创立并开源至今已经7年，作为一个复杂的基础软件来说确实还比较年轻。依赖早期的3个创始人互联网背景出身，深知大家在关系型数据库上的痛点。所以TiDB推出后获得了不少用户的推崇，特别是互联网行业。社区在TiDB的发展中也起到了至关重要的作用，从打磨产品、需求提炼、落地场景总结等。目前TiDB在DBEngines排名为98，进一步证明了基础软件的难度以及作为一款国产数据库在国际化进程中还有很大的空间。从墨天轮中国数据库排行的情况，可以看到TiDB长期以来保持第一的位置。在12月跌落榜首，由OceanBase取代。
　　图片数据来源墨天轮
　　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
　　1hr4C16G200GB（云盘）
　　TIKVTIFLASH
　　3基础规格：8C32G1788G（本地SSD）
　　高配规格：16C64G1788G（本地SSD）数据库备份
　　备份工具：BR〔官方物理备份工具〕
　　备份策略：凌晨低峰期进行数据全量备份
　　备份保留周期：7天在线业务
　　对于在线业务，除了常规的BR备份外会额外调整tikvgclifetime时间为13天，当业务出现误操作时可以恢复三天内任意时间的数据。离线业务
　　TiDB集群离线业务大部分是从上游RDS同步到TiDB的场景。上游RDS会有一份最近的数据，所以对于离线业务只有常规的BR备份。4。3稳定性治理变更管理面向DBA的流程管控
　　上图的流程主要是用于管控非白屏化的TiDB基础设施变更。通过变更文档整理、运维小组Review的机制，确保复杂变更的规范化。面向研发变更的系统管控DMLDDL变更工单风险自动化识别
　　语法检查：DDL与DML类型判断，确保每次执行的内容是同一个类型SQL语法检查，确保提交的SQL语法是正确的
　　合规检查：
　　变更合规性检查，确保提交的SQL是可以按照DBA定义的规范设计（可以使用的字段类型、字段命名、索引命名、索引数量，字段长度由长修改短等限制），简单说就是要么允许，要么不允许
　　风险识别：该项的作用是将允许执行的进行风险识别，研发可以根据风险等级选择执行时间，DBA也能在审批阶段判断是否合理，并修改执行时间。相关风险定义
　　变更类型
　　变更项
　　风险提示
　　DDL
　　Createtable
　　低
　　Addindex测试环境（低）
　　生产环境（表大小，低中高）
　　Addcolumn
　　低
　　Modifycolumn类型有限修改
　　高
　　Modifycolumn长度变长
　　低
　　Dropindex测试环境（低）
　　生产环境（高）
　　Truncatetable测试环境（低）
　　生产环境（高）
　　DML
　　updatedelete测试环境（低）
　　生产环境（修改数量，低中高）
　　insert
　　低
　　下图是基于以上提到的能力，实现的TiDB变更管控功能。
　　稳定性巡检
　　数据库巡检手段是相当于告警比较前置的一个动作，巡检阈值相比告警较低，目的是为了提前发现问题并跟进解决。收益是：1。降低告警数量；2。避免小问题逐步积累导致大问题。我们的做法是按照自定义的评分规则，双日晨会对焦，对有风险的服务进行问题跟进。
　　巡检指标的数据采集来自于监控系统，我们会统计相关指标的峰值。每天记录一个点，展示近30天内的指标值。
　　某集群的巡检情况
　　慢查治理
　　虽然TiDB自带的Dashboard可以提供慢查的白屏化，但是这需要提供账号密码给研发，5。0之前的版本还必须使用root账号登录，另外就是我们希望慢查治理可以结合内部系统进行管理。所以对于这部分做了些自研工作，将日志采集并加工后存入ES。DBA平台可以通过报表等手段进行推进治理。
　　下面两张图就是我们内部的平台对慢查治理的闭环管理方案。DBA或者研发TL在平台指派SQL，处理人就会收到治理消息，处理完成后可以在后台进行状态变更。然后基于这些数据可以做报表优化治理效果。
　　告警管理
　　基于TiDB官方的监控方案，我们在告警部分做了些定制化，Prometheus中配置的rule触发后会把告警信息推送至我们自己的数据库管理平台OneDBA，由平台处理后进行发送。平台的告警管理模块的实现类似于Alertmanager，不同的我们新增了自定义的需求，比如元信息关联、支持集群指标级别的阈值定义、告警沉默、告警降噪、告警治理闭环（有告警通知和认领，确保及时跟进处理）。另外这里的Prometheus主要功能是做数据采集与告警，数据存储与趋势图查看在公司统一监控平台，降低不必要的存储资源投入。由于我们管理的数据库类型比较多，所以在告警方案上做了收敛。这里讲到的方案就是得物数据库团队目前针对负责的所有数据库的管理方案。
　　阈值管理
　　故障演练
　　故障演练的目的是为了巩固目前的系统高可用。我们针对TiDB制定了一套故意演练流程，包含了8个场景。
　　【演练场景1】TiKVServer1个节点宕机
　　【演练场景2】TiDBServer1个节点宕机
　　【演练场景3】PDServer1个节点宕机
　　【演练场景4】PDServer节点重启
　　【演练场景5】TiKVServer节点重启
　　【演练场景6】应用高并发写入，CPU、IO告警是否及时发送
　　【演练场景7】PDServerLeader、follow节点重启
　　【演练场景8】TiDB集群宕机一个TiDBServer节点
　　以上的场景我们通过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的了解程度和做好它的决心，也给了研发使用的信心。
　　TiDB在核心业务场景实践5。1业务痛点
　　得物商家订单库由早期MySQL单库进阶到MySQL分库分表，这个方案支撑了业务的高速发展。而以商家ID做sharedingkey，会使的同一个商家的订单数据都会在一个表中，随着订单量的逐步提升，最终大商家的查询会形成了单点性能问题。主要体现在慢SQL较多和数据库负载上升，每天约1W条慢SQL，部分统计类查询已经超10S。另外就是单机容量也有上限，垂直扩容受限。随着订单量的上升，系统整体的性能和容量需要最进一步的规划。5。2解决思路
　　优点
　　缺点
　　规格调整简单快速治标不治本成本高
　　数据归档减少单表数据量治标不治本成本高
　　调整分片规则解决数据分布问题数据需要按新的逻辑灌入新集群业务代码需要适配新的分片规则分库分片水平扩展复杂
　　分布式数据库解决上面提到的数据分布问题扩容简单，无需业务感知聚合查询能力新存储的引入需要验证稳定性、性能、兼容性
　　基于以上提到的问题，我们对所有的解决方案都做了对比。表格中是对四种解决方案的关键信息提炼。我们希望能够选择一个比较长期的方案，可以支撑未来35年的需求，既要解决性能问题，还要解决容量问题，又要比较低的研发成本。所以最终选择了引入分布式数据库的方案。5。3数据库选型
　　基于目前得物在使用的数据库进行了评估，主要包含以下三种选择。
　　由于得物在2020年就引入了TiDB。虽然没有大规模推广，但是陆续也有不少业务接入。大部分的业务把它作为MySQL分库分表的聚合库使用，有一小部分业务是直接接入了读写需求。基于之前的实践经验和业务需求，经过和研发团队的协商，直接采用的读写库的使用方案。另外一个方面是从只读过渡到全量读写的周期会比较长，会产生不必要的并行成本和延迟项目时间。5。4兼容性性能测试兼容性测试
　　SQL兼容性的问题，我们并没有完全依赖后期的业务测试来验证。而是通过获取MySQL上的全量SQL的方式进行验证。由于我们将全量SQL存储在了Clickhouse，并且存储前做了SQL指纹提取。所以很容易可以获得去重后的业务SQL。然后将所有类型的SQL样本在TiDB中进行回放，这里主要针对Select。最终测试所有业务SQL100兼容。
　　SQL指纹
　　性能测试单量较少的商家场景性能测试
　　和预期的结果一样，由于TiDB分布式的架构，数据获取路径比MySQL要长，所以RT上相比MySQL分别多出91、76、52。从这里可以看出随着并发的上升，TiDB和MySQL之间的RT差距也逐步缩短。由于TiDB可以通过扩展DB和KV节点提升QPS能力，我们在压测中也做了相关验证，符合预期。包括现有数据量翻一倍的基础上对性能的影响也做了验证，结论是无影响。为了方便和后面的内容对比，我们这里只提供了RT的指标。
　　单量较多的商家场景性能测试
　　我们挑了几个出现频率较高且查询较慢的SQL进行测试，详情参照以下内容。
　　SQL1SELECTFROMtablenameWHERExxid1203030ANDxxstatusIN（4000，3040）ANDisdel0ORDERBYidDESC，createtimeDESCLIMIT20
　　SQL2SELECT〔columnname〕FROMtablenameWHERExxid1203030ANDxxstatus8010ANDclosetype13ANDclosetime‘2022061918：16：24。519LIMIT0，30000
　　SQL3SELECTFROMtablenameWHERExxid1203030ANDxxstatusIN（7000，8000，8010）ANDisdel0ORDERBYidDESC，createtimeDESCLIMIT20
　　SQL4selectcount（）fromtablenameWHERE（sellerid1203030andisdel0andbiztypein（0，12）andcreatetime2021110100：00：00。0andcreatetime2021113023：59：59。0and（xxstatus1000Rbiztype21））
　　关于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执行报Regionisunavailable错误。经排查是5。3。2引入的TiKVbug。
　　PDleader发生切换后，TiKV向PDclient发送心跳请求失败后不会重试，只能等待与PDclient重连。
　　这样，故障TiKV节点上的Region的信息会逐步变旧，使得TiDB无法获取最新的Region信息，导致SQL执行出错。
　　解决方案：
　　这是一个让人后背发凉的bug。当时的判断是由于PD切换导致的，但是不清楚是bug。我们采用了影响最小的故障恢复方案（把PDleader切回去，因为原PDLeader没有挂，只是发生了切换）。问题解决后在官方发现了这个bugfix。所以又安排了升级。
　　这是我们上线过程中遇到的几个典型问题。总体来说引入一个新数据库就会带来一定的试错成本，所以我们依然处于谨慎选型的状态。另外就是吐槽一下，就上面的问题2，建议官方要加强CodeReview和混沌工程演练。5。6上线效果性能收益
　　为了确保上线稳定性，我们通过灰度切流的方式逐步放量。完全切流后成果显著，慢SQL几乎全部消失，如下图所示。
　　成本收益
　　由于MySQL的分库分表集群由10个写实例、10个读实例构成，迁移至TiDB后的集群规模为TiDB6、TiKV12。成本下降了58。所以再重复说一下选对了场景，TiDB也能顺带节省成本。大促考验
　　项目上线后轻松应对了今年的双11、双12，大促中的系统RT表现稳定。
　　总结
　　最后特别说明下，文章中涉及一些产品的对比只是基于我们当时的场景和需求进行的分析，并不代表某个数据库产品的好坏。写这篇文章的目的是想把我们TiDB落地经验做个阶段性总结，顺便也能给同行们做个大方向上的参考。我们的这套方法论，理论上适用于任何一个需要再企业内部引入新型数据，并且推广的场景。本文涉及的内容和方向比较多，无法每个模块都做深入的探讨。后面我们也会把大家感兴趣的模块单独拆分出来做几期深入分享。
　　文xiaoyu
　　关注得物技术，每周一三五晚18：30更新技术干货
　　要是觉得文章对你有帮助的话，欢迎评论转发点赞