TiDB Server 架构
TiDB Server 的主要功能：
一条SQL的执行流程：
1.将整个SQL语句解析成一个个的token，生成一个树形结构。
2.编译模块
1.首先需要做一个合法性验证，比如表存不存在等。
2.做逻辑优化：依据关系型代数等等价变换的规则做一些逻辑变换，比如：列裁剪，最大最小消除，谓词下推，子查询，谓词下推，把外连接变为内连接等等。
3.做物理优化：根据数据的分布，数据的大小，决定用哪个算子。比如：用全表扫描还是用索引扫描，用哪个索引等。
4.最终生成执行计划，拿着执行计划就到TiKV节点中取相应的数据，此外我们还需要统计信息（数据分布与行数）和元数据（表名，列名，索引名是什么等属性）。
关系型数据 进行KV转化操作流程
假设现在有一张聚簇表 编号为主键PK。
聚簇表其实就是把相同聚簇键放在相同或相邻的数据块中，这样从而提高了聚簇因子的效率，从而提高了查询速度。
首先主键就是天然的Key，把主键和其它数据分开。
但在数据库中 编号为1的key肯定不止一个，也就是说它再数据库层面全局不是唯一的。所以我们需要再加一个表的编号
这时候Value的每一行都有了一个唯一的Key。这样就转换成了KV的形式
把所有的KEY VALUE存储在一块，就形成了region（每个region在96M-144M之间）。
当region 达到144M的时候，会有一个region分裂的过程。把一个region分成两个region
读写相关模块协作：
Onlie DDL相关模块协作：
如图，TiDB Server可以有很多个 ，可能向多个TiDB Server 上执行DDL，在对于整个TiDB 数据库来讲，同一时刻只能由一个TiDB Server 做DDL操作，也就是workers。 也就是同一时刻，只有一个TiDB Server 中的workers可以做操作。
TiDB DDL流程：
首先一个DDL过来，首先由TiDB Server 中的start job模块接收。接收之后，start job模块会把这个DDL 以job的形式放到TiKV中的job队列中。（感觉这里有点疑问，之前说TiDB Server的操作都要由TiKV client 发给TiKV，所以这里应该由start job模块发给TiKV client ，TiKV client 再以job的形式发给TiKV）
这个队列是所有TiDB Server接收的DDL job一个总的队列。在同一时间只有一个TiDB Server的角色为owner，owner中的worker模块负责从job队列中去取第一个job去执行（这个job可以不是owner发出的DDL，但也是由owner去执行），执行完再把该job放到history job。每个TiDB Server是轮换当owner的，谁成为owner，谁就激活workers去执行job队列。
job放到TiKV中是为了持久化
GC机制与相关模块：
GC负责定期清理MVCC历史版本的数据。有一个GC会当选为GC leader，由它来执行GC操作。比如，现在是下午两点，计算出上午十点钟是一个safe point。 那么从上午十点到下午两点的数据都会保留，之前的数据将会由GCleader 清除。
TiDB 会定期进行 GC。每次 GC 时，TiDB 首先会计算一个时间戳，称为“安全点”。然后，TiDB 会在确保安全点之后的所有快照都保留数据完整性的前提下，清除过时的数据。具体来说，每次 GC 过程涉及三个步骤：
- 解决锁。在此步骤中，TiDB 会扫描所有 Region 上安全点之前的锁，并清除这些锁。
DROP TABLE删除范围。在此步骤中， /操作生成的整个范围的过时数据DROP INDEX将被快速清除。- 执行 GC。在此步骤中，每个 TiKV 节点都会扫描其上的数据并删除每个键的不需要的旧版本。
默认配置下，每10分钟触发一次GC，每次GC会保留最近10分钟的数据，也就是说GC生命周期默认为10分钟（安全点=当前时间-GC生命周期）。如果一轮GC运行时间过长，在这一轮GC完成之前，即使到了触发下一次GC的时间，下一轮GC也不会启动。另外，为了让长事务在超过GC生命周期后仍能正常运行，安全点不会超过正在进行的事务的开始时间（start_ts）。
TiDB Server 的缓存
热点小表缓存
当一张表只占一个region，又不能拆散，那么所在TiKV就会繁忙。
解决问题就是不要访问TiKV 了，直接把这张表放在内存的 cache table中。
热点小表缓存原理：
首先，存到内存中的表大小需要小于64M。
如何保证读写一致？
