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