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'; 

DDL

• OceanBase支持传统数据库的DDL语句，自动完成全局统一的schema变更，无需用户在多节点间做schema一致性检查
• DDL任务由OceanBase的RootServer统一调度执行，保证全局范围内的schema一致性
• 对于所有支持的 DDL 操作都是 OnLine 的，DDL不会产生表锁，在执行 DDL 的过程中不会阻塞业务的读写操作
• DML根据schema信息的变更自动记录格式，对业务零影响
• DML与DDL互相不阻塞，提高性能