SQL 查询优化 | 青训营笔记

88 阅读2分钟
这是我参与「第四届青训营」笔记创作活动的的第1天.

在大数据体系中,SQL是属于分析引擎部分,以往我只接触过单机的数据库,没有深入了解引擎部分,而分析又分为批式分析,实时分析(Flink),交互分析

SQL的处理流程:

SQL-->Parser-->Analyzer-->Optimizer-->Executor

Parser :AST(abstract syntax tree)

词法分析:拆分字符串,得到token,语法分析,将token组成AST node,最终得到AST;

实现: 递归下降(ClickHouse) Flex JavaCC Antlr

Analyzer&Logical Plan

Analyzer:检查绑定元信息,SQL合法性检查;

Logical Plan:逻辑的描述SQL对应的分步骤计算操作(算子)

Optimizer:找到一个正确且代价最小的物理执行计划

Plan Fragment(执行计划子树):最小化网络数据传输,利用数据的物理分布(数据亲和性);

Executor:单机并行(Cache),多机并行(一个fragment对应多个实例)

常见优化器

Top-down:从目标输出,由上往下遍历计划树,找到完整的最优计划(SQLServer,Volcano)

Bottom-up:由下往上遍历计划书,找到完整执行计划(PostgreSQL,IBM DB2)

Rule-based Optimizer(RBO) 基于启发式规则,根据关系代数等价语义,重写查询; 会访问元信息(catalog),不会涉及表数据

Cost-based Optimizer(CBO) 使用一个模型估算执行计划代价,选择最小代价的计划;

RBO优化原则:

从I/O方面 read data less and faster;
从网络方面 Transfer data less and faster;
从CPU方面 Process data less and fater;

优点:实现简单,优化速度快; 缺点:不保证得到最优的执行计划;

CBO 算子代价:CPU,内存,I/O等代价

根据推到规则计算算子代价,执行计划代价,通过枚举执行计划得到最小执行计划(贪心,动态规划等)

前沿趋势

对SQL OPtimizer 有更高要求 引擎结构进化(存储计算分离) Cloud(云原生) 湖仓一体 DATA&AI;

AI4DB:自动调节参数,自优化,自诊断自愈合(错误恢复和迁移)

DB4AI:内嵌AI算法,ML框架;

总结: 在听了这节对SQL查询优化器浅析课程,对数据库引擎有了一些了解.在大数据环境下,单机数据库已经不再适用,对数据搜索以及查找有更高的要求,以往的查询方式开销大,也对大数据的前景以及SQL的处理流程有了更深的了解,虽然实现起来还有很大困难,在数据结构,操作系统上的实现还不是很清晰;