一 DML语句读写流程

1 DML语句读流程概要

用户发出SQL

被协议层接收 Protocal Layer

通过PD获取时间戳

parse模块解析SQL，通过词法解析与语法解析生成AST语法树

编译SQL Compile模块 ,区分点查与非点查，生成执行计划发送给Executor,从TIKV获取数据返回给用户

2 DML语句读流程概要

写流程和读流程前面差不多，需要先把数据读出来

二 DDL语句的执行流程

在集群中有多个tidb server .可能有多个DDL 发送到TiDB server上。但是同一时刻只能有一个TiDB server的workers在做DDL

用户发出DDL语句由模块 start job 模块接收，然后放到job queue队列中。

在同一时刻只有一个Tidb Server的角色为owner ,owner角色的 Tidb Server的worker才能中从 job queue队列中取DDL，执行完成之后放到history queue中。

owner 角色有任期，并不是固定在一个Tidb Server上。

当成为owner后，schema load 会收集所有表的元数据。

队列放到TiKV上主要是为了持久化存储，一旦发生宕机断电可以防止数据丢失。

SQL解析 Parse 与编译 Compile

用户发出SQL ，由协议层接收， PD Client 请求PD 获取TSO ，这条SQL语句起始时间，Parse模块对SQL进行语法解析词法解析yacc, 转化为AST 语法树，语法树被传递到 Compile模块,细分有三步 1 Proprocess预处理阶段检测SQL合法性名称是否正确，绑定的信息等，另外还会判断是否为点查（比如通过唯一索引主键索引的等值查询），这样就不用在走后面的流程，直接执行。如果不是点查，则还需要走后面的优化流程，分为逻辑优化（主要是根据关系代数，等价交换的一些规则对SQL语句进行逻辑的变换，比如外连接转换为内连接），逻辑优化之后就是物理优化主要是基于逻辑优化的结果结合表的统计信息（表的行数，列的选择度，直方图等等）选择最优的算子，从Compile模块出来的就是物理执行计划，就可以去TiKV中取数。

读取的执行

有了执行计划之后读取的流程主要设计的模块在TIDB server中

Executor 执行器

KV 专门负责点查的

DistSQL 执行复杂SQL的

PD Clent 负责与PD沟通

TiKV Client 通过这个出入口与TiKV 交互

Executor 需要做两件事 1 获取元数据，在TIDB 启动的时候，information schema是存储了元数据的，已经被载入到Tidb Server的缓存中了，所以直接读缓存就可以了。2 另外还有KEY所在的Region ，Region所在的TiKV等这些信息存储在PD中，所以还需要访问PD，但是TiDB Server 与 PD 是通过网络交互的，频繁的交互有很大的网络压力，如何解决把读取过的信息缓存在TIKV Client的 Region Cache中，下一次再读取相同的Region的时候就去 Region Cache中读取即可。如果存储Region的TIKV发生了变化（region 分裂合并过期等），根据TIKV Client的 Region Cache的信息就获取不到数据，然后就需要返回，这种现象叫做back Off，出现back Off响应就会延迟，就会再去PD中读取一次。因为PD中的数据是最新的。

下面就可以去TIKV中读数据了。

DIstSQL 是一个抽象层，把复杂的SQL语句转换为对单表的简单查询，之后在去下发给TIKV ，这样就相当于吧复杂SQL与TIKV 进行了解耦合。

TIKV接收到SQL请求之后，首先会构造一个快照，snapshot,一个特定时间点的数据，比如我十点发出SQL，这样查询的数据永远是十点的。从TIDB 5.0之后无论是点查还是复杂查询查都会进入到 UnifyRead Pool 线程池，按照优先级执行这些查询的，然后到rocksdb kv中查询，rocksdb kv的查询也是分层的由上而下 blockCache -->MEMTable--> Immutable -->MEMTable，可以参考【TiDB理论知识 03】TiKV-持久化与数据读取_DBA之路的博客-CSDN博客

这样数据就取出来了。

单表的SQL不一定在一个TIKV上，这个时候可以并行查询。TIKV 还具有算子下推功能，会帮助TiDB 做数据的过滤和聚合，这种叫做 cop task 。还有一部分 TIKV 没有办法比如做T1 T2 T3表的三表连接，数据可能散落在各个TIKV上，只能把数据先放到 TIDB的内存中，然后再做表连接，叫做 root task