The lifecycle of a SQL in TiDB

导读

作者:杨漆
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的负载高) 在这里插入图片描述
  6. parse的耗时(一般只有bash insert 时耗时高)、Compile的耗时(包括预处理和优化,一般在复杂查询时慢)从DashBoard对应面板可以看到
  7. 开启Prepared statements 提高parse和预处理的开销(通过prepare statement count可查看该功能是否生效)
  8. 开启Prepared Plan cache,节省optimizing开销(通过Plan Cache hits可查看该功能是否生效) 在这里插入图片描述
  9. Execution duration 查看整体执行阶段耗时
  10. Expensive execution查看复杂算子的OPS(可通过调整tidb_{operator}_concurrency来降低延迟)
  11. Tikv请求耗时、region error导致延时过高(一般由region cache过期导致)、锁冲突高导致在这里插入图片描述
  12. DistSQL是TiDB 向Tikv发送请求、接收数据的接口
  13. DiskSQL Duration可以看出DiskSQL请求的延时(tidb_distsql_scan_concurrency控制并发度参数,当延迟大时可调节该参数来降低延迟)
  14. Scan Keys体现扫描的数据量,会影响延迟在这里插入图片描述
  15. 事务在Tikv的耗时高主要体现在 Local Latch 和 事务重试
  16. Local Latch:Tidb在commit前对事务排序用的锁(默认为关闭),当锁冲突较多时可以打开。耗时情况在Dashboard的sql statement & slow queries 和Grafana的Local Latch Wait Time中可以监控到
  17. 事务重试只在一部分事务出现错误时进行尝试(如:写冲突),重试次数在Dashboard的sqlstatement & slow queries 和 Grafana的Transaction Retry Num中可以监控到在这里插入图片描述
  18. Tikv通过gRPC接收到请求。
  19. 写请求通过scheduleràraftstoreàRocksDBraftàRocksDB kv阶段
  20. 读请求通过ReadpoolàRocksDB kv
  21. 在RocksDB中先会WAL,访问memtable,若没命中访问block cache,还没命中就访问SST在这里插入图片描述
  22. gRPC上反映了TiKV请求的延迟,包括上图指标
  23. 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在这里插入图片描述
  24. 每个Tikv有两个RocksDB实例,分别用于存储raft日志和KV数据
  25. 读数据时先读Memtable,没有命中读block cache,再没命中读SST
  26. 写数据的相关 监控在write duration中查看
  27. RocksDB在后台做compaction (operations 代表次数,duration代表耗时)在这里插入图片描述
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值