1、TiDB总览

1.1、TiDB Server架构

TiDB Server 是无序的，不存储数据。

• (Protocol Layer/Parse/Compile)： 负责SQL语句解析和编译(优化)。
• (DistSQL/KV/Executor)： 执行生成的计划。 简单的SQL(例如直接通过主键查到)使用KV,DistSQL复杂SQL执行计划的生成。
• (Transaction/KV)：这个和负责事务处理相关的进行。
• (PD Client/TiKV Client)：这个负责与PD和TiKV 交互的进程。 例如获得时间戳TSO,就是通过PD Client跟PD获取。
• (schema load/worker/start job)： 这三个进程主要负责online ddl
• memBuffer: 缓存当中的数据，类似sga
• cache table: 缓存表的内存区域。
• GC: 垃圾回收,将MVCC过期版本数据进行回收

1.2、TiDB Server 主要功能：

• 处理客户端的链接
• SQL 语句的解析和编译
• 关系型数据与 KV 的转化
• SQL 语句的执行
• Online DDL 的执行（DDL 操作不会阻塞读写，但对整个 TiDB 来说，同一时刻只能有一个 TiDB Server 进行 DDL 操作）
• 垃圾回收
• 热点小表缓存
• 多个 TiDB Server 轮换选举 Owner 节点，Owner 中的 worker 负责执行 DDL
• DDL job 会存储在 TiKV 中进行持久化
• TiDB 是用 Go 开发的
• TiDB Server GC 默认 10 分钟触发一次，删除当前时间上一个 safe point 之前的历史版本数据
• 热点小表缓存，限制表数据需在 64m 以下，可通过 ALTER TABLE users CACHE; 将 users 表放入 TiDB Server 的 cache table 中。
• 热点小表缓存如何保证读写一致的问题：tidb_table_cache_lease=5 参数控制缓存租约。5s 之内用户可以从缓存中读取数据；租约到期前，任何用户不能修改此表，租约过期后，写数据直接写入 TiKV，读也是从 TiKV 读，完成写操作之后，缓存重新续约，缓存内容也会刷新。所以当租约到期时，读性能会下降。不支持对缓存表直接做 DDL 操作，需要先关闭。
• TiDB 中的表分为两种：聚簇表、非聚簇表。聚簇表需要有主键，非聚簇表可以有主键，也可以没有。KV 转换时，聚簇表使用主键作为 key，非聚簇表不管是否定义了主键，都会生成一个 key。
• Protocol Layer 通过 PD Client 异步向 PD 请求 TSO，同时继续进行 SQL 解析和编译，在实际执行前，获取异步请求 TSO 的结果

2、SQL语句处理

**功能：**负责客户端的连接。 连上之后把SQL语句发送过来，所以第二件事就是解析这些语句。 然后生成一个分布式的执行计划。它是无序的，不保何数据。一个挂掉了，通过一些负载均衡技术，连其它的就可以。

语句的解析和编译

把语句拆分成一个个token，生成一个AST语法树

按照已经解析好了执行计划，把这个执行计划给到executor ,然后它按照plan生成的树状执行计划，执行都时候分两种，

• 第一种复杂的SQL例如过滤、范围，关联，嵌套等 防止跟TiKV耦合度太高，中间抽象出一层DistSQL接口。经过DistSQL 都会变成一个个简单的单表计算任务。

• 第二种KV ,简单的SQL,POINT CACHE(点查的模块),例如根据主键或者唯一索引，查看一行或0行记录这种。

SQL层

SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执⾏SQL 解析和优化，最终⽣成分布式执⾏计划。TiDB 层本身是⽆状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统⼀的接⼊地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。

协议层

protocol layer :协议层，能够让tidb在网络层中提供服务，例如mysql 协议的服务，通过之后，然后客户端连上tidb，把SQL语法发过来

上下文

session context: 会话上下文。例如存放用户登录的数据。登录成功后，SQL语句就发送给解析层

解析层

parser: 解析层，当然这个SQL肯定还是要 前往到具体到某台TiKV server上，集群当中的某一个leader上。所以它要去到哪个leader上面呢，它会去问pd(大脑)，要对应的 data location,找到某个tikv server的地址； 另外还有个功能就是将SQL语句变成 树形结构，这个树形结构当中会保存 这条SQL语句要访问的对象以及对这个对象的操作。

逻辑优化器

logical optimizer : 逻辑优化器，
统计信息：通过一系列规则，例如总行数等辅助信息。这些辅助信息有可能对这个SQL语句的执行 起到帮助的作用

物理优化器

physical optimier: 物理优化器，拿到这些统计信息再结合逻辑优化器生成的执行计划。 来生成一个更好的物理执行计划。 这个执行计划会交由两个执行器来处理，

本地执行器

local executor: 如果我有一些命令，需要在客户端 所连的那一台TiDB Server上操作，那这个时候就会 本地执行器来做

分布式执行器

Distributed Executor: 这个SQL，是需要去到TiKV上操作命令的执行，则这些SQL 会交给分布式执行器来处理。 为什么是分布式的，因为TiKV server实际是一个集群，上面执行的SQL是一个并行SQL,它会在多台TiKV server上同时执行这样的SQL

3、如何将表的数据转成kv形式

4、在线DDL相关模块

5、GC机制与相关模块

用于回收mvcc 旧版本，定期清理。 这个动作就叫gc
例如可以设置一个gc lift time = 4hout 则safe point 为4个小时，则四个小时内的数据即使增删改，也可以找到这四小当中的任意数据

6、TiDB Server 缓存

• TiDB Server缓存组成
  • SQL结果
  • 线程缓存
  • 元数据，统计信息
• TiDB Server缓存管理
  • tidb_mem_quota_query
  • oom-action

语句执行过程中，需要的数据会先放到缓存中，这个很类似pga
tidb_meme_quota_query: 限制每条SQL使用的内存，占用缓存的大小
oom-action: 当超过tidb_meme_quota_query这个值后，是如何执行这条SQL(例如中断或者忽略)

7、热点小表缓存

• 表的数据量不大
• 只读表或者修改不频繁的表
• 表的访问和频繁

小表缓存原理

这张表的大小要小于64M才能放到cache
tidb_table_cache_lease: 租约，类似租房的有效期。

热点小表缓存-应用

• TiDB对于每张缓存表的大小限制为64Mb
• 适用于查询频繁、数据量不大、极少修改的场景
• 在租约（tidb_table_cache_lease）时间内，写操作会被阻塞
• 当租约到期（tidb_table_cache_lease）时，读性能会下降
• 不支持对缓存表直接做DDL，需要先关闭
• 对于表加载较慢或者极少修改的表，可以适当延长tidb_table_cache_lease 保持读性能稳定