个推技术实践 | 掌握这两个调优技巧，让TiDB性能提速千倍！

知识就是力量，时间就是生命。这篇文章主要讲述个推技术实践 | 掌握这两个调优技巧，让TiDB性能提速千倍！相关的知识，希望能为你提供帮助。
北京冬奥会上，运动健儿们激战正酣，他们正在用速度、力量、韧性诠释更快、更高、更强的奥林匹克精神，向他们致敬！其实，在0和1的计算机世界里，开发者和程序员们为了提升系统运行速度、最大化释放服务器性能，也要面对各种各样的挑战，不断提出方案，展开实践，以突破瓶颈、解决难题。

个推“大数据降本提效”专题，正是通过总结分享自身在大数据实战过程中的踩坑经验、调优技巧等，为从业人员开展大数据实践提供参考。本文是“大数据降本提效”专题的第三篇，将为大家分享个推通过调优，实现TiDB千倍性能提升的实战经验。

个推与TiDB的结缘

作为一家数据智能企业，个推为数十万APP提供了消息推送等开发者服务，同时为众多行业客户提供专业的数字化解决方案。在快速发展业务的同时，公司的数据体量也在高速增长。随着时间的推移，数据量越来越大，mysql已经无法满足公司对数据进行快速查询和分析的需求，一种支持水平弹性扩展，能够有效应对高并发、海量数据场景，同时高度兼容MySQL的新型数据库成为个推的选型需求。

经过深入调研，我们发现“网红”数据库TiDB不仅具备以上特性，还是金融级高可用、具有数据强一致性、支持实时HTAP的云原生分布式数据库。因此，我们决定将MySQL切换到TiDB，期望实现在数据存储量不断增长的情况下，仍然确保数据的快速查询，满足内外部客户高效分析数据的需求，比如为开发者用户提供及时的推送下发量、到达率等相关数据报表，帮助他们科学决策。

完成选型后，我们就开始进行数据迁移。本次迁移MySQL数据库实例的数据量有数T左右，我们采用TiDB自带的生态工具Data Migration (DM)进行全量和增量数据的迁移。

全量数据迁移：从数据源迁移对应表的表结构到TiDB，然后读取存量数据，写入到TiDB集群。
增量数据复制：全量数据迁移完成后，从数据源读取对应的表变更，然后写入到TiDB集群。

个推将MySQL数据迁移到TiDB

当数据同步稳定之后，将应用逐步迁移到TiDB Cluster。把最后一个应用迁移完成之后，停止DM Cluster。这样就完成了从MySQL到TiDB的数据迁移。

注：DM的具体配置使用详见官方文档。

陷入TiDB使用的“反模式”

然而，当应用全部迁移到TiDB之后，却出现了数据库反应慢、卡顿，应用不可用等一系列的问题。

如下图：

登陆数据库时遇到卡顿

通过排查，我们发现有大量的慢SQL都是使用load导入数据的脚本。

慢SQL的导入耗时几十分钟

和业务方沟通后，我们发现有些导入语句就包含几万条记录，导入时间需要耗时几十分钟。

对比之前使用MySQL，一次导入只需几分钟甚至几十秒钟就完成了，而迁到TiDB却需要双倍甚至几倍的时间才完成，几台机器组成的TiDB集群反而还不如一台MySQL机器。

这肯定不是打开TiDB的正确姿势，我们需要找到原因，对其进行优化。

单个服务器负载过高

通过查看监控，发现服务器负载压力都是在其中一台机器上（如上图，红色线框里标注的这台服务器承担主要压力），这说明我们目前并没有充分利用到所有的资源，未能发挥出TiDB作为分布式数据库的性能优势。

打开TiDB的正确使用姿势

首先优化配置参数

具体如何优化呢？我们首先从配置参数方面着手。众所周知，很多配置参数都是使用系统的默认参数，这并不能帮助我们合理地利用服务器的性能。通过深入查阅官方文档及多轮实测，我们对TiDB配置参数进行了适当调整，从而充分利用服务器资源，使服务器性能达到理想状态。

下表是个推对TiDB配置参数进行调整的说明，供参考：

重点解决热点问题

调整配置参数只是基础的一步，我们还是要从根本上解决服务器负载压力都集中在一台机器上的问题。可是如何解决呢？这就需要我们先深入了解TiDB的架构，以及TiDB中表保存数据的内在原理。

在TiDB的整个架构中，分布式数据存储引擎TiKV Server负责存储数据。在存储数据时，TiKV采用范围切分（range）的方式对数据进行切分，切分的最小单位是region。每个region有大小限制（默认上限为96M），会有多个副本，每一组副本，成为一个raft group。每个raft group中由leader负责执行这个块数据的读& 写。leader会自动地被PD组件（Placement Driver，简称“PD”，是整个集群的管理模块）均匀调度在不同的物理节点上，用以均分读写压力，实现负载均衡。

TiDB架构图（图片来源于TiDB官网）

TiDB会为每个表分配一个TableID，为每一个索引分配一个IndexID，为每一行分配一个RowID（默认情况下，如果表使用整数型的Primary Key，那么会用Primary Key的值当做RowID）。同一个表的数据会存储在以表ID开头为前缀的一个range中，数据会按照RowID的值顺序排列。在插入（insert）表的过程中，如果RowID的值是递增的，则插入的行只能在末端追加。

当Region达到一定的大小之后会进行分裂，分裂之后还是只能在当前range范围的末端追加，并永远仅能在同一个Region上进行insert操作，由此形成热点（即单点的过高负载），陷入TiDB使用的“反模式”。

常见的increment类型自增主键就是按顺序递增的，默认情况下，在主键为整数型时，会将主键值作为RowID ，此时RowID也为顺序递增，在大量insert时就会形成表的写入热点。同时，TiDB中RowID默认也按照自增的方式顺序递增，主键不为整数类型时，同样会遇到写入热点的问题。

在使用MySQL数据库时，为了方便，我们都习惯使用自增ID来作为表的主键。因此，将数据从MySQL迁移到TiDB之后，原来的表结构都保持不变，仍然是以自增ID作为表的主键。这样就造成了批量导入数据时出现TiDB写入热点的问题，导致Region分裂不断进行，消耗大量资源。

对此，在进行TiDB优化时，我们从表结构入手，对以自增ID作为主键的表进行重建，删除自增ID，使用TiDB隐式的_tidb_rowid列作为主键，将
create table t (a int primary key auto_increment, b int)；
改为：
create table t (a int, b int)SHARD_ROW_ID_BITS=4 PRE_SPLIT_REGIONS=2

通过设置SHARD_ROW_ID_BITS，将RowID打散写入多个不同的Region，从而缓解写入热点问题。

此处需要注意，SHARD_ROW_ID_BITS值决定分片数量：

SHARD_ROW_ID_BITS = 0 表示 1 个分片
SHARD_ROW_ID_BITS = 4 表示 16 个分片
SHARD_ROW_ID_BITS = 6 表示 64 个分片

SHARD_ROW_ID_BITS值设置的过大会造成RPC请求数放大，增加CPU和网络开销，这里我们将SHARD_ROW_ID_BITS设置为4。

PRE_SPLIT_REGIONS指的是建表成功后的预均匀切分，我们通过设置PRE_SPLIT_REGIONS=2，实现建表成功后预均匀切分2^(PRE_SPLIT_REGIONS)个Region。

经验总结

· 以后新建表禁止使用自增主键，
考虑使用业务主键
· 加上参数SHARD_ROW_ID_BITS = 4 PRE_SPLIT_REGIONS=2

此外，由于TiDB的优化器和MySQL有一定差异，出现了相同的SQL语句在MySQL里可以正常执行，而在TiDB里执行慢的情况。我们针对特定的慢SQL进行了深入分析，并针对性地进行了索引优化，取得了不错的成效。

优化成果

通过慢SQL查询平台可以看到，经过优化，大部分的导入在秒级时间内就完成了，相比原来的数十分钟，实现了数千倍的性能提升。

慢SQL优化结果

同时，性能监控图表也显示，在负载高的时刻，是几台机器同时高，而不再是单独一台升高，这说明我们的优化手段是有效的，TiDB作为分布式数据库的优势得以真正体现。

优化后，实现服务器负载均衡

总结
作为一种新型分布式关系型数据库，TiDB能够为OLTP（Online Transactional Processing）和OLAP（Online Analytical Processing）场景提供一站式的解决方案。个推不仅使用TiDB进行海量数据高效查询，同时也展开了基于TiDB进行实时数据分析、洞察的探索。

后续更多“大数据降本提效”的干货分享，请大家持续锁定个推技术实践公众号（微信公众号ID：getuitech）~

【个推技术实践 | 掌握这两个调优技巧，让TiDB性能提速千倍！】