D29 - 热点

分散式资料库理论上会把业务的loading平均分布到各个node上。但是仍有可能因为业务逻辑或者资料库本身的机制导致失衡，热点便是这些情况下的产物。loading只落在其中一个node上，导致整个cluster的效能低落。

TiDB的热点是怎麽产生的，与资料分配的Key ID有关。TiDB对每一张表、索引、每一行资料都会分配一个ID。
TiKV保存资料的方式是把一连串连续的Key保存在一个Region里，当达到特定大小的时候，会分裂成两个Region。
当我们写入的资料是依序的，如前面提到的Auto_increment，此时Region虽然会因为资料持续写入达到设定的大小而分裂出新的Region，但是实际上还是针对一个Region做写入。遇到高并发的写入时便对写入产生了热点。

我们可以从grafana的监控上查看目前是否存在读/写的热点。

也可以下语法查看

select * from information_schema.TIDB_HOT_REGIONS where type = 'read'
select * from information_schema.TIDB_HOT_REGIONS where type = 'write'

读取的热点通常发生在表的本身资料不多，所以region也少。TiKV提供了Load Base Split的方式，依据这两个参数split.qps-threshold与split.byte-threshold，每十秒QPS与流量的统计值来协助判断是否要拆分新的Region。qas预设是3000，流量则是30MB/s。

写入热点的解决分式，则可以透过SHARD_ROW_ID_BITS把ROWID写入不同的Region，但是在使用上只限於使用NONCLUSTERED Primary Key的表。除此之外也可以用AUTO_RANDOM替换AUTO Increment。