大数据学习-SQL Optimizer | 青训营笔记

SunriseXue
1,043 阅读3分钟

大数据学习-SQL Optimizer | 青训营笔记

这是我参与「第四届青训营 」笔记创作活动的的第2天

SQL在大数据引擎中应用广泛，我在上一篇文章中已经讲到了,那么今天我们就来了解一下SQL，首先是SQL的处理流程

SQL的处理流程，

image.png 这里我直接用了课程视频的截图，大家可以看到当一个SQL语句被执行的时候，首先会由Parser进行处理，通过分析语句中的词法和语法将获得的token组成AST node，

根据我浅陋的知识MYSQL在这之前还会进行一个查询缓存的操作，当查询命中缓存时（就是查到了），MYSQL就会跳过之后的步骤直接返回，但查询缓存失效在实际业务场景中可能会非常频繁，所以MYSQL直接在8.0删掉了这个功能。

最终返回一个AST（abstract syntax tree），即抽象语法树，之后经过Analyzer检查语法、数据库表等是否存在返回一个Logical Plan，即逻辑计划，它应该就是一个二叉树（还没学数据结构QAQ）树上的每个结点都是一个 算子（operator） 描述一些join之类的操作，之后经过Optimizer找到最有效的运行方案输出一个Physical Plan给Executor,

查询优化器分类

  • Optimizer即查询优化器的存在是因为SQL是一种声明式语言，当我们输入一个SQL语句比如select * from 的时候只制定了在哪找，没指定怎么找，所以为了有效的调度资源输出一个正确且执行代价最小的物理执行计划，就需要optimizer的存在了

  • 按照遍历树的逻辑顺序可以分为Top-down Optimizer和Bottom-up Otimizer优化器

  • 根据优化方法可以分为Rule-based Optimizer(RBO) 和 Cost-based Optimizer(CBO) ，现在的系统两种方法都用

    Rule-based Optimizer(RBO)

根据关系代数等价语义，重写查询，再根据启发式规则，会访问表的元信息（catalog），不会涉及具体的表数据（data）;

优化原则：读、传、处理数据更少更快

列裁剪：将join的表中不需要遍历的列进行裁剪 image.png 谓词下推：将where表达式中的内容后推执行 image.png 传递闭包：根据表达式的等价关系和过滤条件推导出新的条件 image.png Runtime Filter:提早过滤一些不必要的数据在join段 image.png 等几百条基于经验归纳得到的优化规则

  1. 优点：实现简单，优化速度快
  2. 缺点：不保证得到最优的执行计划

Cost-based Optimizer(CBO)

使用一个模型估算执行计划的代价，选择代价最小的执行计划

算子代价：CPU,内存，磁盘I/O，网络I/O等代价，不同模型代价不同

统计信息+推导规则 -> 计算算子代价 -> 计算执行计划代价 -> 执行计划枚举

> 统计信息

原始表统计信息

  • 表或者分区级别：行数、行平均大小、表在磁盘中占用了多少字节等。

  • 列级别：min、max、num nulls、num not nulls、num distinct value(NDV)、histogram等 推到信息

推导统计信息

  •  选择率(selectivity)：对于某一个过滤条件返回的数据比例。

  •  基数（cardinality):在查询计划中常指算子需要处理的行数。
> 推导规则

假设列和列之间是独立的，列的值是均匀分布的

image.png

> 执行计划枚举

CBO在执行时要一个个去枚举CBO没法解决的问题，通常使用贪心算法或者动态规划选出最优的执行计划来找到局部的或全局的最优解，讲到算法就牡蛎了

> 小结

大数据场景下CBO对查询性能非常重要

avatar
文章
阅读
粉丝