TiKV学习5：TiDB SQL执行流程

1. DML语句读流程概要

2. DML语句写流程概要

3. DDL 流程概要

4. SQL的Parse和Compile

5. 读取的执行

6. 写入的执行

7. DDL的执行

8. 小结

1. DML语句读流程概要

TiDB Server接收sql并处理，TiKV负责持久化数据，PD提供TSO和Region的数据字典信息

Protocol Layer：接收sql
PD Client到PD节点获取STO
Parse：词法解析、语法解析，将sql解析为AST语法树
Compile：区分点查和非点查，生成执行计划
Execute：拿着执行计划问PD在哪个TiKV Region读取想要的数据
读出来的数据放在memBuffer中进行修改，当用户发起commit的时候，进入两阶段提交
- 第一阶段：prewrite，将内存中修改的信息和锁信息写入TiKV
- 第二阶段：commit，写提交信息，将锁清理掉，获取结束TSO
二阶段提交完成后，返回给用户提交成功数据不会丢了

修改表定义、加索引等等都是DDL

当Executor收到执行计划后，Executor做两件事：

①从information schema（缓存中，是最新的）中获得元数据（表名、列名等）
②要修改的数据对应Key在所在的Region以及Region所在的TiKV，第一次会从PD中获取Region的位置，然后缓存在TiKV Client中的region Cache中，如果region Cache的信息过期了(back off)，访问的时候会再次从PD中读取最新的信息到region Cache中

经过了以上过程，获得了表的元数据以及Key所在的Region和TiKV

Executor读取数据：

TiKV接收到请求后首先会构建一个快照snapshot

点查和非点查都会进入UnifyRead Pool线程池，按照优先级执行查询，到RocksDB kv去读取数据

一部分过滤和聚合在TiKV中做，叫coptask，还有一部分在TiDB中(比如三张表连接，三张表散落在3个TiKV中，先把数据读到TiDB内存中再做表连接)叫root task

前面的读取流程是一样的，从读出数据开始，把需要修改的数据读到memBuffer中，用户commit后进入两阶段提交

第一阶段：prewrite，Transaction从memBuffer中一行一行读取数据修改数据，通过KV和TiKV Client写到TiKV中并加锁

写请求发送给Scheduler模块(协调事务并发写入的冲突，并将收到的修改操作向下写入)，同时写入同一个Key的时候，谁持有Latch谁就可以写数据，其他的需等待Latch
然后到RaftStore，将写请求转换为raft log，此时会在本地RocksDB raft持久化raft log，并把raft log发送给其他节点，然后Apply模块把读取rocksdb raft log应用到rocksdb kv中持久化存储，然后反馈写入成功。

第二阶段：commit，获取结束TSO，写提交信息，清理锁

Protocol Layer接收DDL，经过Parse和Compile，到达start job
start job会检查自己所在的TiDB Server是不是owner
如果是owner则直接给workers执行，如果不是就会把DDL做成一个job放到TiKV的job queue中持久化（添加索引放在add index queue中）
Schema load：将最新的表的元信息载入到TiDB Server
owner中的worker会定期去查看job queue，当job queue中有job的时候workers就根据元信息执行DDL（Job queue 和 add index queue 中的语句可以并行执行）
执行完毕后把job放在history queue中

owner节点是轮询的，由PD节点控制