课程名称： 3.7.2 The lifecycle of a SQL and relevant metrics
学习时长：40min
课程收获：
了解了SQL在TiDB和TiKV中的流程，并了解相关监控项
课程内容：
SQL在TIDB组件中的流程
1、在处理sql前，先获取token
2、事务开始前获取start ts（异步获取）
3、parser解析为AST树，进行预处理，执行逻辑优化和物理优化，在开启prepare statement并命中时，会跳过解析和预处理阶段，在开启prepare plan cache并命中时，会跳过解析、预处理、优化阶段
4、执行器根据物理优化执行，事务结束后，获取commit ts 并且commit
监控各阶段
1、get token阶段
token用于限制同时执行的sql数量，避免TiDB被打挂，如果gettoken耗时过高，证明达到了token上限，有sql在等待。
2、start tso阶段
TSO：wait duration高说明TiDB负载高，RPC duration高说明TiDB和PD之间的网络慢，或者PD的负载高
3、parse阶段
parse一般只有batch insert时耗时高
4、compile阶段
包括预处理和优化两个阶段，预处理包括合法性验证和类型推导，这个阶段一般在复杂查询时慢
开启prepared statement，可以减少parse和预处理的开销,通过prepared statement count可以看出是否生效
prepared plan cache ，还可以节省优化的开销，通过plan cache hits 可以看出是否生效
5、execution duration:可以看出整体耗时
6、expensive executors ops：可以看出负载算子的ops，这些算子可以通过调整并发度减少延迟
7、KV request：可以看出TiKV的请求耗时，导致延迟较高的原因包括，region error（region cache过期）、锁冲突较多等
8、Dist SQL:
是tidb向tikv发送请求和接收数据的端口，distsql是并发发送的
1、DistSQL duration：可以看出请求的延迟，可以通过tidb_distsql_scan_concurrency调整降低延迟
2、scan keys:体现扫描的数据量
3、coprocessor & get & batch get:kv request ops
9、事务
1、KV Transaction duration：事务在TiKV的耗时
2、local latch:在事务commit前，对事务排序用的锁，默认是关闭的，将锁冲突较多时可以打开
3、 Transaction retry：指在出现一部分错误时会尝试，例如锁冲突
SQL在TiKV组件中的流程
1、通过grpc接收请求
2、写请求和读请求分别走不同的流程
3、写请求会经过scheduler、raftstore、rocksDB raft、rocksDB kv等阶段
4、读请求会经过readpool、rocksDB kv等阶段
5、 在rocksdb中会先写wal,访问memtable，没有命中再访问block cache,再没命中就访问SST
监控各阶段
1、gRPC message duration：反应了TIKV上处理请求的延迟
2、事务部分：prewrite和commit、resolve lock
3、raftstore模块：发生在写流程中，用于把raftlog同步到所有副本，raft propose(propose wait duration/apply wait duration )和raft io (appendlog/applylog/commitlog)
4、coprocessor模块：执行时间（request duration），等待时间（wait duration），如果等待时间长，可以通过打开coprocessor cache,通常与处理的数据量相关
5、rocksDB：每个TiKV有两个rocksDB实例，一个用来存储raft日志，一个用来存储用户数据，在读数据时，先读memtable，没命中再读block cache,再不命中读SST，写数据(write duration),compaction(compaction operations(次数)/compaction duration（耗时）)
学习过程中遇到的问题或延伸思考：
- 问题 1：
- 问题 2：
- 延伸思考 1：
- 延伸思考 2：