大数据学习-SQL Optimizer | 青训营笔记
这是我参加「第四届青训营 」笔记创作活动的的第2天
SQL在大数据引擎中运用广泛，我在上一篇文章中已经讲到了,那么今日咱们就来了解一下SQL，首先是SQL的处理流程
SQL的处理流程，
依据我浅薄的常识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的表中不需求遍历的列进行裁剪
谓词下推：将where表达式中的内容后推执行 传递闭包：依据表达式的等价联系和过滤条件推导出新的条件 Runtime Filter:提前过滤一些不必要的数据在join段 等几百条根据经验归纳得到的优化规矩
- 优点：完成简略，优化速度快
- 缺点：不保证得到最优的执行方案
Cost-based Optimizer(CBO)
运用一个模型估算执行方案的价值，挑选价值最小的执行方案
算子价值：CPU,内存，磁盘I/O，网络I/O等价值，不同模型价值不同
计算信息+推导规矩 -> 核算算子价值 -> 核算执行方案价值 -> 执行方案枚举
> 计算信息
原始表计算信息
-
表或许分区等级：行数、行平均大小、表在磁盘中占用了多少字节等。 -
列等级：min、max、num nulls、num not nulls、num distinct value(NDV)、histogram等 推到信息
推导计算信息
-
挑选率(selectivity)：关于某一个过滤条件回来的数据份额。 -
基数（cardinality):在查询方案中常指算子需求处理的行数。
> 推导规矩
假定列和列之间是独立的，列的值是均匀分布的
> 执行方案枚举
CBO在执行时要一个个去枚举CBO无法解决的问题，通常运用贪心算法或许动态规划选出最优的执行方案来找到部分的或全局的最优解，讲到算法就牡蛎了
> 小结
大数据场景下CBO对查询性能十分重要
