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

SQL Optimizer是SQL查询优化器

SQL 查询优化在 OLAP 应用当中至关重要的主要原因是： SQL 是一种声明式(Declarative)的编程语言，相比一般的编程语言描述的是程序执行的过程，这类编程语言则是描述问题或者需要的结果本身。具体的执行步骤则交由程序自己决定。

从使用的角度，SQL 作为一种可以被非相关技术人员快速入手的编程语言，其主要优点就在于即使用户因并不了解数据库内部的实现细节而写出来十分糟糕的查询语句，只要表达的意思准确清楚，数据库就可以在一定程度上将其转化为合理的执行方案高效的返回结果，极大的降低了使用门槛。因此一个好的查询优化器，也是关系型数据库重要的卖点之一。

从技术的角度来说，通过对用户输入的查询进行优化，实现更优的执行步骤规划 数据库可以实现更快的执行和更少的 IO 消耗。从而节约资源提高性能。

• SQL 经过 Parser 分析成为一个抽象语法树
• String --> AST(abstract syntax tree）
• AST 经过 Analyzer 进行 SQL 分析输出逻辑任务
• optimizer 面对非单机的大数据查询，海量数据下优化很重要（影响查询速度）
• 将优化后的逻辑计划拆分 --> 将拆分后的 fragment 进行执行,每个 node 有多个实例（跨节点传输效率较低）

• Top-dowm Optimizer
• Bottom-up Optimizer
• RBO：Rule-based Optimizer
• CBO：Cost-based Optimizer

也即“基于规则的优化器”，该优化器按照硬编码在数据库中的一系列规则来决定SQL的执行计划。

以Oracle数据库为例，RBO根据Oracle指定的优先顺序规则，对指定的表进行执行计划的选择。比如在规则中：索引的优先级大于全表扫描。

通过Oracle的这个例子我们可以感受到，在RBO中，有着一套严格的使用规则，只要你按照规则去写SQL语句，无论数据表中的内容怎样，也不会影响到你的“执行计划”，也就是说RBO对数据不“敏感”。这就要求开发人员非常了解RBO的各项细则，不熟悉规则的开发人员写出来的SQL性能可能非常差。

但在实际的过程中，数据的量级会严重影响同样SQL的性能，这也是RBO的缺陷所在。毕竟规则是死的，数据是变化的，所以RBO生成的执行计划往往是不可靠的，不是最优的。

也即“基于代价的优化器”，该优化器通过根据优化规则对关系表达式进行转换，生成多个执行计划，然后CBO会通过根据统计信息(Statistics)和代价模型(Cost Model)计算各种可能“执行计划”的“代价”，即COST，从中选用COST最低的执行方案，作为实际运行方案。

CBO依赖数据库对象的统计信息，统计信息的准确与否会影响CBO做出最优的选择。

以Oracle数据库为例，统计信息包括SQL执行路径的I/O、网络资源、CPU的使用情况。

目前各大数据库和大数据计算引擎都倾向于使用CBO，例如从Oracle 10g开始，Oracle已经彻底放弃RBO，转而使用CBO；而Hive在0.14版本中也引入了CBO。

• 已搜索完成的物理计划的代价最小值成为 Cost Upper Bound。当新的搜索分支的代价高于它时，不需继续搜索。初始 Cost Upper Bound 可由优化器根据启发式规则估算。

• 存储计算分离
• HSAP, HTAP, HTSAP
• Cloud Native, Serverless
• 数据仓库，数据湖，湖仓一体，联邦查询
• 智能化
  • AI4DB
  • DB4AI

• 主流的查询优化器都包含 RBO 和 CBO
• Apache Caicite 是大数据领域很流行的查询优化器
• Apache Caicite RBO 定义了许多优化规则，使用 pattern 匹配子数，执行等价变换。
• Apache Caicite CBO 基于 Volcano/Cascade 框架
• Volcano/Cascade 的精髓：动态规则、剪纸

1. 【大数据专场 学习资料一】第四届字节跳动青训营 - 掘金 (juejin.cn)
2. MySQL存储引擎介绍_!NULL_YM的博客-CSDN博客_什么是mysql存储引擎