首先优化配置参数
具体如何优化呢？我们首先从配置参数方面着手。众所周知，很多配置参数都是使用系统的默认参数，这并不能帮助我们合理地利用服务器的性能。通过深入查阅官方文档及多轮实测，我们对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 个分片, 默认值 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。
- PRE_SPLIT_REGIONS 的值必须小于或等于 SHARD_ROW_ID_BITS
经验总结
· 以后新建表禁止使用自增主键，
考虑使用业务主键
· 加上参数SHARD_ROW_ID_BITS = 4 PRE_SPLIT_REGIONS=2
此外，由于TiDB的优化器和MySQL有一定差异，出现了相同的SQL语句在MySQL里可以正常执行，而在TiDB里执行慢的情况。我们针对特定的慢SQL进行了深入分析，并针对性地进行了索引优化，取得了不错的成效。
优化成果
通过慢SQL查询平台可以看到，经过优化，大部分的导入在秒级时间内就完成了，相比原来的数十分钟，实现了数千倍的性能提升。
慢SQL优化结果
同时，性能监控图表也显示，在负载高的时刻，是几台机器同时高，而不再是单独一台升高，这说明我们的优化手段是有效的，TiDB作为分布式数据库的优势得以真正体现。
优化后，实现服务器负载均衡
