【OceanBase】21.SQL引擎组件概述

1.SQL请求执行流程
SQL请求执行流程-词法/语法解析

SQL请求
|
Parser------------>
|                 |
Resolver<----(未命中)Plan Cache
|                 |
Transformer   	  |
|                 |
Optimizer         |(命中)
|                 |
Code Generator    |
|                 |
Executor<---------|
|
返回结果

Parser（词法/语法解析模块）：得到"语法树"
在收到用户发送的SQL请求串后，Parser会将字符串分成一个个
的“单词”，并根据预先设定好的语法规则解析整个请求，将
SQL请求字符串转换成带有语法结构信息的内存数据结构，我们称为“语法树”（Syntax Tree）

为了加速SQL请求的处理速度，OceanBase对SQL请求采用了特有的“快速参数化”，
以加速查找plan cache的速度。该步骤生成的结果是内存"语法树"。

2.SQL请求执行流程-语义解析:得到"语句树"

Resolver（语义解析模块）：
当SQL请求字符串经过语法、词法解析，生成“语法树”之后，
resolver会进一步将该语法树转换为带有数据库语义信息的"内部数据结构"

在这一过程中，resolver将根据数据库元信息将SQL请求中的
token翻译成对应的对象（例如库、表、列、索引等），生成的数据结构叫做Statement Tree(语句树)

3.SQL请求执行流程-逻辑改写:查询改写

Transformer（逻辑改写模块）：
在查询优化中，经常利用等价改写的方式，将用户SQL转换为与之等价的另一条SQL，
以便于优化器为之生成最佳的执行计划，我们称这一过程为“查询改写”

Transformer 在 resolver 之 后 ， 分析用户SQL的语义，并根据内部的规则或代价模型，
将用户SQL“改写”为与之等价的其他形式，并将其提供给后续的优化器做进一步的优化

语法语义前端
|
基于规则重写
|  |
基于代价重写
|  |
查询优化器
|
执行

4.SQL请求执行流程-优化器

Optimizer（优化器）：

优化器是整个SQL请求优化的核心，其作用是为SQL请求生成最佳的执行计划
在优化过程中，优化器需要综合考虑SQL请求的语义、对象数据特征、对象物理分布等多方面因素，
解决访问路径选择、连接顺序选择、连接算法选择、分布式计划生成等多个核心问题，最终
选择一个对应该SQL的最佳执行计划为了充分利用OceanBase的分布式架构和多核计算资源的优势，
OceanBase的查询优化器会对执行计划做并行优化：根据计划树上各个节点的数据分布，
对串行执行计划进行自底向上的分析，把串行的逻辑执行计划改造成一个可以并行执行的逻辑计划

5.SQL请求执行流程-代码生成器

Code Generator（代码生成器）：
优化器负责生成最佳的执行计划，但其输出的结果并不能立即执行，
还需要通过代码生成器将其转换为可执行的代码，这个过程由Code Generator负责
Code Generator执行的过程只是忠实地将优化器的生成结果翻
译成可执行代码，并不做任何优化选择

6.SQL请求执行流程-执行器

Executor（执行器）：
◼ 对于本地执行作业，Executor会简单的从执行计划的顶端的
算子开始调用，由算子自身的逻辑完成整个执行的过程，并返回执行结果
◼ 对于远程或分布式作业，Executor需要根据预选的划分，将
执行树分成多个可以调度的job，并通过RPC将其发送给相关的节点执行

7.SQL请求执行流程-执行计划缓存

Plan Cache（执行计划缓存模块）：
执行计划的生成是一个比较复杂的过程，耗时比较长，尤其是在OLTP场景中，这个耗时往往不可忽略
为了加速SQL请求的处理过程，SQL执行引擎会将SQL第一次生成的执行计划缓存在内存中，
后续对该SQL的重复执行可以复用这个计划，避免了重复查询优化的过程.

8.执行计划快速参数化

将SQL进行参数化（即将SQL中的常量转换为参数），然后使用参数化的SQL文本作为键值在Plan Cache中获取执
行计划，从而达到仅参数不同的SQL能够共用相同的计划目的。
• 参数化过程是指把SQL查询中的常量变成变量的过程。
• 传统数据库在进行参数化时一般是对语法树进行参数化，然后使用参数化后的语法树作为键值
在Plan Cache中获取计划，而OB是使用的词法分析对文本串直接参数化后作为Plan Cache的键值。

SQL请求 -->快速参数化-->计划缓存-----(命中)--->执行计划
						|     |                | |
						|    约束条件生成------->| |
						|	  |                  |
					词法/语法解析                  |
                        |                        |
						语义解析----->优化器---代码生成

9.执行计划快速参数化-参数化过程举例

--请求的SQL（无不能参数化的常量）
select * from t1 where c1 = 5 and c2 = 'oceanbase';
--经过词法分析后得到的参数化SQL
select * from t1 where c1 = @1 and c2 = @2;
--参数数组
{5,'oceanbase'}

--请求的SQL（存在不能参数化的常量）
select * from t1 where c1 = 5 and c2 = 'oceanbase' order by 1;
--经过词法分析后得到的参数化SQL
select * from t1 where c1 = @1 and c2 = @2 order by @3;
--参数数组
{5,'oceanbase',1}
--约束条件
快速参数化参数数组的第3项必须为数字1

10.执行计划快速参数化-常量不能参数化的场景

◼ 所有 ORDER BY 后常量（例如"ORDER BY 1,2;"）
◼ 所有 GROUP BY 后常量（例如"GROUP BY 1,2;"）
◼ LIMIT 后常量（例如"LIMIT 5;"）
◼ 被物化的参数精度数字（例如"NUMBER(10,2);"）
◼ select投影列中常量（例如"select 1 as id from tab;"）
◼ 作为格式串的字符串常量（例如"DATE_FORMAT('2006-06-00', '%d'); "里面的"%d"）
◼ 函数输入参数中，影响函数结果或带有隐含信息并最终影响执行计划的常量（例如
"CAST(999.88 as NUMBER(2,1))"中的"NUMBER(2,1)"，或者"SUBSTR('abcd', 1, 2)"中的"1, 2"，
或者"SELECT UNIX_TIMESTAMP('2015-11-13 10:20:19.012');" 里面的"2015-11-13 10:20:19.012"，
指定输入时间戳同时，隐含指定了函数处理的精度值为毫秒）

11.执行计划快速参数化-常量不能参数化举例

表t1中含c1, c2列，其中c1为主键列，两条SQL只有order by常量不同
select c1, c2 from t1 order by 1;
select c1, c2 from t1 order by 2;

12.总结

c1为主键，当使用主键访问可以免去排序，当需要对 c2 排序，则需要执行显示的排序操作。因此，不能将order by 后面的常量参数化，否则会导致不同order by的值参数化后具有相同的参数化后的SQL，从而命中错误的计划。
Parser:语法语义解析:得到"语法树"
Resolver:语义解析:得到"语句树"
Transformer:逻辑改写:查询改写 
Optimizer:为SQL请求生成最佳的执行计划
Code Generator:将优化器的生成结果翻译成可执行代码
Executor:执行执行计划并返回结果。
Plan Cache:SQL执行引擎会将SQL第一次生成的执行计划缓存在内存中,后续重复使用。