SQL请求执行流程

基本流程跟传统数据库没有区别。

1、SQL请求进来后，先进行Parser语法解析、解析完成后看是否有内存缓存，若有缓存则直接到执行器，进行SQL执行。若无缓存，则进行硬解析。

2、语法解析完成后，进行Resolver语义解析。--->Transformer 进行查询改写。--->Optimizer优化器进行生成执行计划---->Code Generator代码生成器将执行计划，生成可执行的代码。---->Executor执行器负责代码的执行。包括本地作业和远程、分布式作业。

执行计划快速参数化

传统的数据库，以oracle为例，执行计划缓存是按照“SQL文本”进行优化并缓存执行计划，根据“SQL文本”在缓存中快速查找执行计划，提高sql解析效率。

OB数据库是将SQL文本进行参数化，将常量替换为绑定变量。然后拿着替换后的“SQL文本”到内存中查找执行计划。

不能快速参数化的场景

所有 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-1310:20:19.012');" 里面的"2015-11-13 10:20:19.012"，指定输入时间戳同时，隐含指定了函数处理的精度值为毫秒）

快速参数化的优劣点思考

优势：

更少的内存，能缓存更多的sql执行计划。

减少硬解析次数，提高并发。

劣势：

对于有数据倾斜的表可能造成执行计划不良，sql执行效率忽高忽低。select id，name，status from t where status='GREEN'; status 一共就三个值，green，red， yellow，且绝大数据数据都是green。---->解决办法：select id，name 'GREEN' as status from t where status='GREEN'; select id，name ，'YELLOW' as status from t where status='YELLOW'; select id，name ，'RED' as status from t where status='RED';