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。
如何保证读写一致？
