写点什么

京东云 TiDB SQL 优化的最佳实践

  • 2022-10-18
    北京
  • 本文字数:1966 字

    阅读完需:约 1 分钟

京东云TiDB SQL优化的最佳实践

京东云 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 协议,使迁移使用成本降到极低。


作者:赵玉龙

发布于: 刚刚阅读数: 3
用户头像

拥抱技术,与开发者携手创造未来! 2018-11-20 加入

我们将持续为人工智能、大数据、云计算、物联网等相关领域的开发者,提供技术干货、行业技术内容、技术落地实践等文章内容。京东云开发者社区官方网站【https://developer.jdcloud.com/】,欢迎大家来玩

评论

发布
暂无评论
京东云TiDB SQL优化的最佳实践_数据库_京东科技开发者_InfoQ写作社区