TiDB 在京东云丨TiDB SQL 优化最佳实践

本文作者：赵玉龙

京东云与 PingCAP 深度合作，联合推出了一款云上分布式数据库产品，向京东云用户提供云上的 TiDB 服务。它可以同时支持 OLTP 和 OLAP 混合负载场景，实现了自动水平伸缩，强一致性的分布式事务，部署简单，在线异步变更表结构不影响业务。

由于 TiDB 兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB，使迁移使用成本降到极低。下表从总体上概括了 TiDB 和 MySQL 的兼容策略：

SQL 是 DBA 和广大开发人员操作数据库的主要手段，几乎每天都在使用。那么它是如何工作的？我们又如何让它更高效地工作？本篇文章将详细介绍 TiDB SQL 的架构、优化流程以及最佳实践。

TiDB SQL 层架构

用户的 SQL 请求会直接或者通过 Load Balancer 发送到 京东云TiDB Server，TiDB Server 会解析 MySQL Protocol Packet，获取请求内容，对 SQL 进行语法解析和语义分析，制定和优化查询计划，执行查询计划并获取和处理数据。数据全部存储在 TiKV 集群中，所以在这个过程中 TiDB Server 需要和 TiKV 交互，获取数据。最后 TiDB Server 需要将查询结果返回给用户。

一条 SQL 的生命周期图：

SQL 优化流程概览：

在 TiDB 中，从输入的查询文本到最终的执行计划执行结果的过程可以见下图：

在经过了 parser 对原始查询文本的解析以及一些简单的合法性验证后，TiDB 首先会对查询做一些逻辑上的等价变化，通过这些等价变化，使得这个查询在逻辑执行计划上可以变得更易于处理。在等价变化结束之后，TiDB 会得到一个与原始查询等价的查询计划结构，之后根据数据分布、以及一个算子具体的执行开销，来获得一个最终的执行计划，同时，TiDB 在执行 PREPARE 语句时，可以选择开启缓存来降低 TiDB 生成执行计划的开销。

使用 EXPLAIN 语句查看执行计划：

执行计划由一系列的算子构成。和其他数据库一样，在 TiDB 中可通过 EXPLAIN 语句返回的结果查看某条 SQL 的执行计划。

目前 TiDB 的 EXPLAIN 会输出 5 列，分别是：id，estRows，task，access object， operator info。执行计划中每个算子都由这 5 列属性来描述，EXPLAIN 结果中每一行描述一个算子。每个属性的具体含义如下：

EXPLAIN ANALYZE 输出格式：

和 EXPLAIN 不同，EXPLAIN ANALYZE 会执行对应的 SQL 语句，记录其运行时信息，和执行计划一并返回出来，可以视为 EXPLAIN 语句的扩展。EXPLAIN ANALYZE 语句的返回结果中增加了 actRows, execution info,memory,disk 这几列信息：

举个例子如下：

从上述例子中可以看出，优化器估算的 estRows 和实际执行中统计得到的 actRows 几乎是相等的，说明优化器估算的行数与实际行数的误差很小。同时 IndexLookUp_10 算子在实际执行过程中使用了约 9 KB 的内存，该 SQL 在执行过程中，没有触发过任何算子的落盘操作。

SQL 优化案例最佳实践

案例一：索引的错误选择导致 SQL 变慢的优化实践

场景：数据库迁移到 TiDB，SQL 在 MySQL 运行不到 1s，在 TiDB 运行超过 30s

SQL 执行计划如下：

execution info 列，有该执行计划的时间，这个 SQL 的表的连接顺序，要从最里面的循环开始看，如下图，m,d 是最先开始进行连接的：

关注下图的 time 变化，执行计划由毫秒级变成了秒级的地方，由 71ms 变成了 33s，所以瓶颈卡在（（m join d） join taskm）join taskd 这个地方，对应的 SQL 片段如下：

INNER JOIN taskd
ON taskd.no = d.no 
 AND taskd.o_no = d.o_no 
 AND taskd.d_no = d.d_no 
 AND taskd.w_no = d.w_no 
 AND taskd.g_no = d.g_no 
 AND IF(NULL = d.MD5_VALUE, 1, d.MD5_VALUE) = IF(NULL = d.MD5_VALUE, 1, taskd.MD5_VALUE) 
 AND taskd.yn = 0

优化思路：

1、首先观察 explain analyze 结果，看到慢在最内 3 层的 join 上 ，(m join d) join taskd；

2、对比 MySQL 的执行计划，发现 MySQL 最内的 3 层的 join 是 (m join d) join taskm, 所以把相关的 3 张表提取出来，修改其 join 顺序；

3、修改顺序后，join 的时间能减少但是和 MySQL 差距还是很大，再次观察，发现 taskd 上 TiDB 和 MySQL 使用的索引不一样，所以使用了 use index 来强制 TiDB 走和 MySQL 相同的索引。

案例二：表关联的错误选择导致 SQL 变慢的优化实践

场景：在 MySQL 运行时间毫秒级别，在 TiDB 运行时间 18s

在 TiDB 的运行时间及执行计划

优化前后的执行计划：

优化后加了 hint 的 SQL：

优化思路：

 1. TiDB 执行耗时 10+s 的原因是对 wps 表的估算不准确，导致优化器认为 w 表 和 p 表 走 hash join 效率更高，然后我们看到的执行计划的主要耗时在 pri 表回表获取数据的耗时较长 ；

2. w 表估算不准确的原因为 TiDB 会把 w 的条件有 range scan 转换点查，然后利用这个索引的统计信息去估算；

3. 点查估算是会利用对应的 CMSketch 去进行估算，结合 p 表数据量很大，根据经验推测可能是 CMSketch 内部 hash 冲突导致。

案例一、二的延伸扩展：

在 SQL 优化的工作中，经常会通过加 hint 的方式改变 SQL 的执行计划，从而达到了优化的目的，但是缺点是对 SQL 进行了硬编码，如果业务程序使用了ORM 框架，SQL 的改造难度会增加。SQL Binding（SPM）则很好的解决了硬编码的问题，通过 SQL Binding，DBA 可以在不改变 SQL 文本的情况下，优化 SQL 的执行计划，从而达到优化的目标，从而使 SQL 优化变得更加优雅。