6-苗青利-TiDB 应用开发实践（二）1

TiDB 应用开发实践（二）- TiDB SQL 监控及典型的优化案例 TiDB 作为通用分布式数据库产品，存在 SQL 性能问题，轻则某个业务 SQL 执行慢，重则某个 SQL 就能引发集群整体性能下降或不可用。本课程从原理 + 实践的角度分析导致 slow-query 原因，并且针对常见的原因提供一些优化思路。 TiDB 读请求的执行流程： 1. 客户端的 Socket 读取一条 SQL 2. 获取一个 token 3. 从 PD 获取 TSO（事务的时间戳） 4. 使用 Parser 将 SQL parse 为 AST 5. 将 AST compile 为执行计划 6. Logical Optimizer、Physical Optimizer、Execute Plan 7. 根据对应的执行计划，最底层的 Executor 会根据这条 SQL 处理的 Key 范围构建出多个要下发到 TiKV 的请求，并通过 distsql 的 API 将这些请求分发到 TiKV 8. TiKV 对结果做一些处理（包括 filter、limit 等）后，将中间结果集反馈给 TiDB 9. TiDB 进行一些表关联、聚合运算等最终反回给 Client TiKV 收到请求后，会将请求分为两类： 1. storage read pool：负责主键或唯一索引点查 2. coprocessor：其余的请求 slow query 产生的原因： 1. TiDB 解析慢 * parse 慢可能原因：TiDB 节点 CPU 压力大 2. TiDB 编译慢 * compile 慢的可能原因：TiDB 节点 cpu 压力大、in 子查询结果集多，跟参数 tidb_opt_insuqquery_unfold 有关（2.1） 3. 获取 token 慢 * token 个数不足，需要调整 token-limit 4. PD 获取 TSO 慢 * PD Leader 切换、PD Leader 节点异常，包括 cpu、磁盘等 5. TiKV 扫描大量的 key * 需要扫描大量的 key、Coprocessor cpu 打满 6. 读热点 * 造成读热点，cpu 资源占满 slow query 的获取渠道： 1. 集群监控上的 metrics 信息 2. slow-query log，对标 Mysql 格式，支持市场上的 mysql 慢查询分析工具 3. TiDB 的慢查询 SQL 内存表 4. TiKV 节点日志 slow-query 反查 TiDB 的 Parse、Compile、Get Token Duration Metrics： 1. TiDB - Parse Metrics * 位置：TiDB -> Executor -> Parse Duration * parse 慢可能原因：TiDB 节点 CPU 压力大 2. TiDB - Compile Metrics * 位置：TiDB -> Executor -> Compile Duration * compile 慢的可能原因：TiDB 节点 cpu 压力大、in 子查询结果集多，跟参数 tidb_opt_insuqquery_unfold 有关（2.1） 3. TiDB - Get Token Duration Metrics * 位置：TiDB -> Server -> Get Token Duration * 可能慢的原因：token 个数不足，需要调整 token-limit PD 的 tso Metrics： 1. PD - tso * 位置：PD -> Grpc -> 99% completed_cmd_duration_seconds -> txn * 可能慢的原因：PD Leader 切换、PD Leader 节点异常，包括 cpu、磁盘等 TiKV 的 Grpc Duration Metrics 和 Coprocessor Cpu： 1. TiKV - Grpc Duration Metrics * 位置：TiKV -> Grpc -> Coprocessor * 可能慢的原因：需要扫描大量的 key、Coprocessor cpu 打满 2. TiKV - Coprocessor Cpu * 位置：TiKV -> Thread Cpu -> Coprocessor Cpu * 可能慢的原因：扫描大量的 key，将 cpu 资源占满、读热点，造成 cpu 资源占满