<span>tidb总览</span>

1）适用于高并发度和高吞吐量的业务，百万级别的qps，稳定的延迟

1）在业务初期，数据量不大，业务流量和压力不大的时候，基本随便什么数据库都能够搞定，但很多时候业务的爆发性增长可能是没有办法预期的

2）省掉了开发人员去分库分表的代价，去掉中间件

3）目前tidb单集群最大的节点数大概是40+个，单表有最大上千亿条记录。

4）活动流量高峰可直接新增机器就能解决，平常流量很低，咱们就可以直接下掉多余机器

5）存储是tikv的一个集群，计算是tidb的一个集群，这样就实现了存储与计算分离。

1）计算主要需要cpu和内存

2）存储主要是磁盘容量和磁盘io

数据访问热点问题，是用户比较关注的问题。

1）问题原因：很多从 MySQL 迁移到 TiDB 的业务，迁移前会使用自增主键，将随机写转为顺序写提高性能。而这种方式，在写入 QPS 较大的 TiDB 集群上，会造成写入热点，原因是 TiDB 使用 range 的方式来进行数据分片，导致新写入的数据集中在一个 range 范围所在的节点，对于这部分写入就会退化成单机的写入性能，未能利用分布式读写扩展的优势。

2）不能解决小表热点问题，由于 PD 的热点调度只能以 Region 为粒度，小表通常只在一个 Region 中，PD 就无能为力了。Load Base Split 会基于统计信息自动拆分 Region。通过统计去识别出那些读流量在 10s 内持续超过阈值的 Region，并在合适的位置将这些 Region 拆分。