Vastbase G100核心技术介绍之【SQL by pass技术】

在传统关系数据库中，对于SQL处理一般分为三个阶段：

Ø  词法语法分析：主要是将用户的输入文本（SQL）转化成一个内部的数据结构，一般称之为语法解析树，并验证语法的正确性，终得到一个表示SQL的语法解析树。

Ø  查询优化：将前一个阶段的语法解析树，进行基于规则以及基于物理代价的优化，生成一个优的查询计划。

Ø  执行查询计划：将前一阶段生成的查询计划予以执行（一般采用迭代器的方式），将结果返回给用户。

为了加速SQL的处理，针对前两个阶段，一般使用类似query plan cache的方式，以避免对SQL进行重复的解析和生成查询计划，例如使用常见的PBE方式（prepare bind execute）。

对于第三个阶段，为了加速查询计划的执行，在很多数据库中采用了基于LLVM的JIT技术，这种主要是在典型的OLAP应用中，针对特定的逻辑生成固定的字节码，提高CPU的执行效率。而在我们面对的OLTP场景中，创新的使用了SQL by pass来提高查询计划的执行效率。

SQL by pass的主要作用是针对某些简单的SQL生成的查询计划。如果查询计划是一个符合特定条件的查询计划，那么可以跳过原有的迭代器模型的执行步骤，直接执行查询计划，将原有查询计划的初始化、执行、终结三个步骤集中到一个相邻的代码逻辑中执行，从而缩短了代码路径，使得热代码更加集中，终能够加速查询计划的执行。

查询计划只能是满足下列条件的update insert delete select 语句的查询计划：

Ø 首先，我们创建一张表test_bypass_sq1，并在后两个字段上建立索引。

Ø 然后我们可以看到简单插入一条数据的时候，就使用了SQL by pass的加速，因为这个插入操作的执行计划满足我们前面提到的条件：

Ø 注意，会话级别的参数enable_opfusion控制是否开启SQL by pass这个特性，目前是默认打开。当我们关闭这个参数之后，就会发现相同的操作有了不同的执行过程：

Ø 因此，没有特殊情况，记得一定不要将该会话参数设置为off。

对于一些简单的select 操作，除了enable_opfusion这个参数外，我们需要额外设置一些参数，使得生成查询计划的顶层节点上是index scan或是index only scan，才能终使用SQL by pass方式来执行。

我们在向test_bypass_sq1插入3条数据之后，执行下面的SQL，可以看到并未使用SQL by pass:

Ø 因为使用了bitmap scan来扫描表，我们禁止掉bitmap scan之后，依然没有使用SQL by pass：

Ø 因为优化器选择了seq scan。我们禁止优化器选择seq scan之后：

Ø 优化器为test_bypass_sq1这个表选择了index scan，终执行时，使用了SQL by pass的执行方式。

同理，对于下面的SQL，优化器为test_bypass_sq1这个表生成了index only scan，终执行时，执行引擎使用SQL by pass方式来加速执行：

Ø 而对于一些复杂的查询，则不能使用SQL by pass：

Ø 因为生成的查询计划的上层节点不是所预期的index scan 或是index only scan 节点，而是一个aggregate节点。

因此，在使用SQL by pass特性时，我们需要关注上述参数、以及该特性对于查询计划的要求，使得优化器能够生成满足SQL by pass的查询计划，终执行引擎能够使用该技术来加速查询计划的执行。

为了对比SQL by pass技术对性能的提升作用，我们采用了如下硬件配置：

使用Vastbase G100数据库，根据TPCC 1000仓，分别针对打开与关闭SQL by pass时，获取tpmC进行性能对比；下面是实际的性能数据：