京东云TiDB SQL层的背景介绍

从总体上概括 TiDB 和 MySQL 兼容策略，如下表：

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 taskdON 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优化变得更加优雅。

京东云联结 PingCAP 基于国内开源 NewSQL 数据库 TiDB 打造的一款同时反对 OLTP 和 OLAP 两种场景的分布式云数据库产品，实现了主动的程度伸缩，强一致性的分布式事务，部署简略，在线异步表构造变更不影响业务，同时兼容 MySQL 协定，使迁徙应用老本降到极低。

作者：赵玉龙