SQL请求执行流程-词法/语法解析
Parser（语法/语法解析模块）
在收到用户发送的SQL请求串后，Parser会将字符串分成一个个的“单词”，并根据预先设定好的语法规则解析整个请求，将SQL请求字符串转换成带有语法结构信息的内存数据结构，我们称为“语法树”（Syntax Tree）
为了加速SQL请求的处理速度，OceanBase对SQL请求采用了特有的“快速参数化”，以加速查找plan cache的速度。
SQL请求执行流程-语义解析
Resolver（语义解析模块）：
当SQL请求字符串经过语法、词法解析，生成“语法树”之后， resolver会进一步将该语法树转换为带有数据库语义信息的内部数据结构
在这一过程中，resolver将根据数据库元信息将SQL请求中的token翻译成对应的对象（例如库、表、列、索引等），生成的数据结构叫做Statement Tree（语句树）
SQL请求执行流程-逻辑改写
Transformer（逻辑改写模块）：
在查询优化中，经常利用等价改写的方式， 将用户SQL转换为与之等价的另一条SQL，以便于优化器为之生成最佳的执行计划，我们称这一过程为“查询改写”
Transformer 在 resolver 之 后 ，分析用户SQL的语义，并根据内部的规则或代价模型，将用户SQL“改写”为与之等价的其他形式，并将其提供给后续的优化器做进一步的优化
SQL请求执行流程-优化器
Optimizer（优化器）：
优化器是整个SQL请求优化的核心，其作用是为SQL请求生成最佳的执行计划在优化过程中，优化器需要综合考虑SQL请求的语义、对象数据特征、对象物理分布等多方面因素，解决访问路径选择、连接顺序选择、连接算法选择、分布式计划生成等多个核心问题，最终选择一个对应该SQL的最佳执行计划
为了充分利用OceanBase的分布式架构和多核计算资源的优势， OceanBase的查询优化器会对执行计划做并行优化：根据计划树上各个节点的数据分布，对串行执行计划进行自底向上的分析，把串行的逻辑执行计划改造成一个可以并行执行的逻辑计划。
SQL请求执行流程-代码生成器
Code Generator（代码生成器）：
优化器负责生成最佳的执行计划，但其输出的结果并不能立即执行，还需要通过代码生成器将其转换为可执行的代码，这个过程由Code Generator负责
Code Generator执行的过程只是忠实地将优化器的生成结果翻译成可执行代码，并不做任何优化选择
SQL请求执行流程-执行器
Executor（执行器）：
对于本地执行作业，Executor会简单的从执行计划的顶端的算子开始调用，由算子自身的逻辑完成整个执行的过程，并返回执行结果
对于远程或分布式作业，Executor需要根据预选的划分，将执行树分成多个可以调度的job，并通过RPC将其发送给相关的节点执行
执行计划快速参数化
将SQL进行参数化（即将SQL中的常量转换为参数），然后使用参数化的SQL文本作为键值在Plan Cache中获取执 行计划，从而达到仅参数不同的SQL能够共用相同的计划目的。
参数化过程是指把SQL查询中的常量变成变量的过程。
传统数据库在进行参数化时一般是对语法树进行参数化，然后使用参数化后的语法树作为键值在Plan Cache中获取计划，而OB是使用的词法分析对文本串直接参数化后作为Plan Cache的键值。
执行计划快速参数化-参数化过程举例
请求的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
执行计划快速参数化-常量不能参数化的场景
1.所有 ORDER BY 后常量（例如"ORDER BY 1,2;"）
2.所有 GROUP BY 后常量（例如"GROUP BY 1,2;"）
3.LIMIT 后常量（例如"LIMIT 5;"）
4.被物化的参数精度数字（例如"NUMBER(10,2);"）
5.select投影列中常量（例如"select 1 as id from tab;"）
6.作为格式串的字符串常量（例如"DATE_FORMAT('2006-06-00', '%d'); "里面的"%d"）
7.函数输入参数中，影响函数结果或带有隐含信息并最终影响执行计划的常量（例如"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"，指定输入时间戳同时，隐含指定了函数处理的精度值为毫秒）
执行计划快速参数化-常量不能参数化举例
表t1中含c1, c2列，其中c1为主键列，两条SQL只有order by常量不同
select c1, c2 from t1 order by 1;
c1为主键，当使用主键访问可以免去排序，当需要对 c2 排序，则需要执行显示的排序操作。因此，不能将order by 后面的常量参数化，否则会导致不同order by的值参数化后具有相同的参数化后的SQL，从而命中错误的计划
通过OBProxy的SQL请求执行流程
OBProxy 包含简单SQL Parser 功能，可进行轻量SQL解析，即先从客户端发出的SQL语句解析出数据库名和表名，再根据用户的租户名、数据库名、表名以及分区ID信息等信息，向OBServer拉取表分区的路由表
查看各阶段耗时
