TiKV学习5：TiDB SQL执行流程

news2024/11/26 3:29:19

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节点控制