共计 2996 个字符，预计需要花费 8 分钟才能阅读完成。
作者：李文杰 网易游戏计费 TiDB 负责人
在应用或运维治理 TiDB 的过程中，大家简直都遇到过 SQL 变慢的问题，尤其是查问相干的读变慢问题。读变慢的问题大部分状况下都遵循肯定的法则，通过教训的积攒能够疾速的定位和优化，不好排查的问题须要从读 TiDB 的每个过程一一排查和剖析解决。
本文针对读 TiDB 集群的场景，总结业务 SQL 在查问忽然变慢时的剖析和排查思路，旨在积淀教训、共享与社区。
一. 读原理
业务 SQL 从客户端发送到 TiDB 集群后，次要经验解析、生成执行打算、执行查问、返回查问后果这几个流程。如下所示是 TiDB 读过程的架构简图：
来自客户端的每个读取数据的操作，TiDB 也会将其封装为读事务，通常状况下事务在执行的过程别离会与 TiDB Server、TiPD Server 和 TiKV Server 进行交互。
TiDB Server
● 用户提交的业务 SQL 通过 Protocol Layer 进行 SQL 协定转换后，外部 PD Client 向 TiPD Server 申请到一个 TSO，此 TSO 即为读事务的开始工夫 txn_start_tso，同时也是该读事务在全局的惟一 ID。
● TiDB Server 在解析前会将 SQL 做分类，分为 KV 点查问（惟一键查问，Point Get）和 DistSQL 简单查问（非点查，Copprocessor）。
○ KV 点查问跳过执行打算优化阶段，间接到查问层，对于在线交易相干的 TP 场景，会大大降低响应提早。
○ 简单的 SQL 查问会被解析、转为形象语法树 AST、编译、基于 RBO/CBO 等优化，会生成真正能够执行的打算。最终生成一个个对单个表拜访的数据申请。
● TiKV Client 模块负责和存储层进行交互，查问申请通过 gRPC 调用，会优先进入 Unified Read Pool 线程池。
TiKV Server
● Unified Read Pool 线程池负责确认查问的数据 Snapshot 和对立调度查问优先级。
○ 新来的查问申请其优先级是最高的，落在 L0 队列里。随着查问工夫越久，为了保证系统整体吞吐量，慢查问的优先级会一直升高，即会从 L0 调低到 L1、L2 等，随着优先级调低其调配到的 CPU 会缩小。
○ 也就是说，一个大查问它越慢，它的优先级就会一直调低，优先级一直调低其执行的工夫可能会更久。所以，尽可能减少大查问事务。
● 查问申请读取 RocksDB 数据
○ 先去 LSM Tree 的 MemTable 查找，最新的数据会写在这里，如果命中则返回。
○ 如果没找到，持续到 Immutable Memory Table 查找，找到则返回。
○ 如果再找不到，则搜查 SST 文件的缓存 Block Cache，找到则返回。
○ 如果还没找到，则会开始读取磁盘 SST 文件，会顺次搜寻 L0 至 L6 各个层级的内容。每一层的文件都会装备一个布隆过滤器。
过滤器对一个 Key 如果判断不存在，那么它肯定不存在这个 SST 文件内，此时能够跳过这个文件；
如果判断在文件内则它可能在可能不在，无奈判断精确，此时会间接去查文件内容，因为 SST 文件严格有序，所以在文件内是效率较高的二分查找。
○ 直到找到数据后，通过 gRPC 调用返回查问后果。
下面形容的过程，大抵就是一个查问申请在 TiDB 集群外部的流转步骤，这也是咱们在遇到读慢时的剖析步骤。
二. 读变慢排查思路
2.1 读慢惯例剖析
业务的 SQL 变慢后，咱们在 TiDB Server 的 Grafana 面板能够看到整体的或者某一百分位的申请提早会升高，咱们依据景象先确认方向性的问题：是整体变慢，还是某个 SQL 变慢。
● 是否整体变慢
○ 剖析各个组件 TiDB、TiKV、TiPD 的响应提早状况
● 整体如果是失常的，持续剖析是不是某类 SQL 变慢
○ 到 Dashboard 查一查慢查问，看一看集群热力求，剖析一下 Top SQL
依据下面的思路，通常就能够对读变慢的问题有一个整体的把握。
接着，和写入变慢的剖析一样，咱们能够顺次排查物理硬件环境、是否有业务变更操作等状况，直到定位分明问题。如下图所示，业务读 SQL 变慢的剖析思路能够有上面步骤：
● 遇到问题咱们应该养成习惯，要先到 Dashboard 看看，对集群运行状况有个整体的把握
○ 查看集群热力求，关注集群高亮的区域，剖析是否有读热点呈现，如果有则确认对应的库表、Region 等信息
热点问题解决 (https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot… 热点问题解决)
○ 排查慢 SQL 状况，查看集群慢查问后果，剖析 SQL 慢查问起因
○ 查看 TOP SQL 面板，剖析集群的 CPU 耗费与 SQL 关联的状况
● 物理硬件排查
○ 排查客户端与集群之间、集群外部 TiDB、TiPD、TiKV 各组件之间的网络问题
○ 排查集群的内存、CPU、磁盘 IO 等状况，尤其是混合部署的集群，确认是否存在资源相互竞争、挤兑的场景呈现
○ 排查操作系统的内核操作是否与官网倡议的最佳实际值是否统一，确认 TiDB 集群运行在最优的零碎环境内
● 业务变更
○ 确认是否是新上线业务
○ 查看集群的 DDL Jobs，确认是否因为在线 DDL 导致的问题，特地是大表加索引的场景，会耗费集群较多的资源，从而烦扰集群失常的拜访申请
2.2 读慢全链路排查
惯例剖析思路能够解决绝大部分的问题，对于剩下那些无奈确认的或较为简单业务的问题，这时候能够剖析读申请从 TiDB Server 到 TiKV Server、到读 RocksDB 的整个过程，对全副查问的链路逐个进行排查，从而确认查问慢所在的节点，定位到起因后再进行优化即可，这一过程大抵如下图所示。
同样地，这个是一个兜底的排查思路，适用范围较广、通用性较强，然而排查起来要花费更多的工夫和精力，也要求管理员对数据库自身的运行原理有肯定的把握。下面的排查步骤还是很简单的，对用户很不敌对。
然而，目前官网曾经推出的 Dashboard 慢查问剖析性能，曾经帮咱们集成和记录了各个环节的提早，再也不必一个一个去查找 Grafana 面板来确认和剖析了，极大地升高排查难度和缩短问题解决时长，是 TiDB 用户的一大福音。
上面是一个慢查问执行时长剖析的例子，能够看到慢查问是因为 TiKV 执行 Coprocessor 工作的累计解决工夫比拟久，所以导致整个查问较慢，咱们再持续针对性剖析和优化 Coprocessor 算子即可。
三. 总结
● 理解 TiDB 的读过程，有助于咱们把握数据库的底层执行原理，遇到问题时能够疾速定位和剖析起因，也能疏导咱们更好地应用数据库，施展其最好的性能。
● TiDB Dashboard 是对用户十分敌对的一个官网工具，它使得咱们剖析慢查问 SQL 变得更轻松和疾速，大大降低了问题解决的工夫，强烈建议应用。
● 上面的官网文档，在剖析此类问题时举荐优先查看：
○ 集群读写提早减少排查 (https://docs.pingcap.com/zh/tidb/stable/troubleshoot-cpu-issues)
○ 热点问题解决 (https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot…)
○ 定位慢查问 (https://docs.pingcap.com/zh/tidb/stable/identify-slow-queries)
○ 剖析慢查问 (https://docs.pingcap.com/zh/tidb/stable/analyze-slow-queries)