SQL Optimizer学习记录 | 青训营笔记

155 阅读2分钟

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

前言:上次课记录了大数据体系以及sql处理流程中的Parser,本节将纪录剩下的Analyzer、Optimizer以及Executor。🎈再次掏出昨天的图:

image.png

Analyzer

由上图可知,对AST抽象语法树进行Analyzer会产出Logical Plan和,然后对其进行Optimizer将会产出Physical Plan。

这里先说明Logical PlanPhysical Plan的不同:例如对于某一段数据处理需要使用排序算法,但是排序的种类有很多种(冒泡、快排、堆排序等)选择怎样的排序方式需要根据具体的应用场景。这里的排序算法就属于Logical Plan,而具体的排序方式(冒泡、快排、堆排序等)则属于Physical Plan

Analyzer包含如下两步:

检查并绑定Database,Table, Column等元信息

SQL的合法性检查,比如min/max/avg的输入是数值

Logical Plan

Logical Plan逻辑地描述SQL对应的分步骤。计算操作计算操作:算子(operator) 例如对于如下sql:

image.png

其对应的左偏树(left deep tree如下)

image.png

Optimizer

  • SQL是一种声明式语言,用户只描述做什么,没有告诉数据库怎么做
  • 目标:找到一个正确且执行代价最小的物理执行计划
  • 查询优化器是数据库的大脑,最复杂的模块,很多相关问题都是 NP的
  • 一般SQL 越复杂,Join 的表越多,数据量越大,查询优化的意义就越大,因为不同执行方式的性能差别可能有成百上千倍

经过Optimizer后将产生

image.png

Executor

与其对应的Plan Fragment:执行计划子树如下

image.png

Plan Fragment:执行计划子树

  • 目标:最小化网络数据传输
  • 利用上数据的物理分布(数据亲和性)
  • 增加Shuffle算子

Executor

  • 单机并行:cache,pipeline,SIMD
  • 多机并行:一个fragment 对应多个实例

总结:

查询优化器是数据库的大脑,在大数据场景下对查询性能至关重要

查询优化器需要感知数据分布,充分利用数据的亲和性

查询优化器按照最小化网络数据传输的目标把逻辑计划拆分成多个物理计划片段