OB的SQL引擎_1
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互相不阻塞,提高性能