SQL查询优化器分析|青训营笔记

165 阅读2分钟

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

1、大数据体系和SQL

SQL->Parser->AST->Analyzer->Logical Plan->Optimizer->Physicial Plan->Executor

Parser: String->AST词法分析token、语法分析token组成AST node 实现:递归下降ClickHouse、Flex和Bison,JavaCC,Antlr

Analyzer: SQL的合法性检查

Logical Plan: 计算操作:算子 left-deep tree

查询优化器:数据库大脑

Physicial Plan: 执行计划子树、增加Shuffle算子

Executor: 单机并行、多机并行

2、常见常见的优化器

RBO:关系代数等价语义,重写查询 基于启发式规则 Select、project、join、rename、union

优化规则: I/O Network CPU&Memory

列裁剪:去掉不需要的列 谓词下推 传递闭包 Runtime Filter

缺点:单表扫描vs全表扫描 Join实现

CBO:选择代价最小的执行计划

统计信息+推导规则

统计信息:原始表、推导:选择率、基数

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

基数(cardinality):在查询计划中常指算子需要处理的行数。

收集方式:

  1. DDL里指定,数据库会在数据写入时收集或更新统计信息
  2. 手动执行exolain analyse statement触发数据库收集或更新统计信息
  3. 动态采样

计算算子代价 计算执行计划代价 执行计划枚举

通常使用贪心算法或动态规划选出最优执行计划

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

查询优化器的社区开源实践:

  • HepPlanner 优化规则(Rule) Pattern :匹配表达式子树 等价变换:得到新的表达式 内置有100+优化规则 四种匹配规则 ARBITRARY/DEPTH FIRST :深度优先 TOP DOWN :拓扑顺序 BOTTOM_ UP :与TOP_ DOWN相反 遍历所有的rule ,直到没有rule可以被触发 优化速度快,实现简单,但是不保证最优

  • Volcano/Cascade 框架

前沿趋势

  • 引擎架构的进化
  • cloud云原生
  • 湖仓一体
  • DATA+AI