**导读**
> 作者：杨漆
> 16年关系型数据库管理，从oracle 9i 、10g、11g、12c到Mysql5.5、5.6、5.7、8.0 到TiDB获得3个OCP、2个OCM；运维路上不平坦，跌过不少坑、熬过许多夜。把工作笔记整理出来分享给大伙儿，希望帮到大家少走弯路、少熬夜。
1. 当Sql进入TiDB时先获取Token,事务开始时获取Start TS (异步方式获取)
2. 由Parse解析为AST树进行预处理（当开启Prepared Statement并命中时会跳过前两步）、逻辑优化（当开启Prepared Plan Cache并命中时会跳过前三步）、物理优化
3. 执行器根据Physical Plan 执行
4. 事务结束获取Commit TS,并进行Commit
5. 整个Sql运行结束
A. 在执行sql之前先获取Token 和Start TS ,Token用于限制sql的并发数，避免TiDB被资源耗尽而挂掉（如果获取Token耗时较高说明达到了Token上限，有sql排队等待）
B. 开始/提交事务都会向PD获取TSO,经历两个阶段：
I．Wait Duration (延迟大时说明TiDB的负载高)
II．RPC Duration (延迟大时说明TiDB和PD之间的传输耗时大，或PD的负载高)
1. parse的耗时（一般只有bash insert 时耗时高）、Compile的耗时（包括预处理和优化，一般在复杂查询时慢）从DashBoard对应面板可以看到
2. 开启Prepared statements 提高parse和预处理的开销(通过prepare statement count可查看该功能是否生效)
3. 开启Prepared Plan cache，节省optimizing开销(通过Plan Cache hits可查看该功能是否生效)
1. Execution duration 查看整体执行阶段耗时
2. Expensive execution查看复杂算子的OPS（可通过调整tidb_{operator}_concurrency来降低延迟）
3. Tikv请求耗时、region error导致延时过高（一般由region cache过期导致）、锁冲突高导致
1. DistSQL是TiDB 向Tikv发送请求、接收数据的接口
2. DiskSQL Duration可以看出DiskSQL请求的延时（tidb_distsql_scan_concurrency控制并发度参数，当延迟大时可调节该参数来降低延迟）
3. Scan Keys体现扫描的数据量，会影响延迟
1. 事务在Tikv的耗时高主要体现在 Local Latch 和 事务重试
2. Local Latch：Tidb在commit前对事务排序用的锁（默认为关闭），当锁冲突较多时可以打开。耗时情况在Dashboard的sql statement & slow queries 和Grafana的Local Latch Wait Time中可以监控到
3. 事务重试只在一部分事务出现错误时进行尝试（如：写冲突），重试次数在Dashboard的sqlstatement & slow queries 和 Grafana的Transaction Retry Num中可以监控到
1. Tikv通过gRPC接收到请求。
2. 写请求通过scheduleràraftstoreàRocksDBraftàRocksDB kv阶段
3. 读请求通过ReadpoolàRocksDB kv
4. 在RocksDB中先会WAL,访问memtable,若没命中访问block cache,还没命中就访问SST
1. gRPC上反映了TiKV请求的延迟，包括上图指标
2. TiDB上的kv request延迟是gRPC 网络延迟的总和(若kv request与gRPC差异大，证明TiDB和Tikv之间的网络延迟大 )
重写和重解析锁在Dashboard中以上两个位置可看到
1． Raft store 发生在写流程中，用来把raft log同步到所有的副本
2． 提raft log( raft propose)
3． 写数据（Raft IO）:append log 是写在日志末尾、apply log 是应用到数据库中、commit log 是提交日志
如果Coprocessor等待时间高可以打开coprocessor cache
1. 每个Tikv有两个RocksDB实例，分别用于存储raft日志和KV数据
2. 读数据时先读Memtable，没有命中读block cache,再没命中读SST
3. 写数据的相关 监控在write duration中查看
4. RocksDB在后台做compaction (operations 代表次数，duration代表耗时)
