高级数据看二十一：查询计划编译

最新推荐文章于 2023-03-29 18:26:40 发布

SuPhoebe

最新推荐文章于 2023-03-29 18:26:40 发布

阅读量913

点赞数

分类专栏：数据库计算机学科学习笔记高级数据库文章标签：数据库

本文链接：https://blog.csdn.net/u013007900/article/details/79063478

版权

计算机学科学习笔记同时被 3 个专栏收录

88 篇文章 17 订阅

订阅专栏

数据库

33 篇文章 5 订阅

订阅专栏

高级数据库

25 篇文章 34 订阅

订阅专栏

Query Compilation

背景

对于in-memory数据库，因为所有的数据都在内存之中，所以很多其他影响速度的因素（如磁盘IO等）都消失了，所以提高吞吐量的唯一方法是减少执行的指令数量。

提高十倍速度，DBMS需要减少90%的指令
提高百倍速度，DBMS需要减少99%的指令

我们可以通过code specialization来实现这种指令数量的减少。即，通过生成DBMS中特定任务的代码来减少指令数量。

大多数代码是为了让人们理解而写的，而不是这样写的效率最高。

接下来的分析都是从逻辑查询计划方面进行分析，但是不是说物理查询计划不会对此造成影响。而是在分析的时候，只要照着逻辑方面进行理解即可

Code Generation / Transpilation

举一个例子

对于如上的数据库，执行如下的操作

SELECT * 
FROM A, C, (
    SELECT B.id, COUNT(*) 
    FROM B 
    WHERE B.val = ? + 1 
    GROUP BY B.id) AS B
WHERE   A.val = 123 
    AND A.id = C.a_id 
    AND B.id = C.b_id

我们根据之前文章上讲到的火山模型，可以得到相应的查询树和查询计划

我们的查询语句会被根据优化器进行重写，重写成Join的形式。

对于人类而言，这写代码以及这种查询树是非常好理解的。但是这段代码对CPU而言就非常不友好:

过多的结构和分支：无论是for还是if都会产生大量的分支，导致CPU要不断刷新管道和缓存。
大量的函数调用：函数调用导致CPU在内存中不断跳跃。

这些都会带来大量的时间损耗。

在执行参数输入的时候，B.val = ? + 1。

为了使得判断语句加快执行，我们也必须将一些其他的信息传入，如，现在所在元组，现在所在元组的位置信息，查询参数。

对于上面的查询树，我们为了处理一个元组，至少需要执行4次函数调用或者类似操作。

这样的代价也是非常大的。

CODE SPECIALIZATION

那么对于上面的操作而言，都是一些通用的更加general的查询编译过程，它支持大多数的查询。

如果在不同的输入上具有相似的执行模式，则可以本地编译任何数据库的CPU密集型实体。即，针对一些特殊的查询进行特定的编译设计。

关于这一点，我觉得大家可以去查一查为什么Python这种弱类型语言的执行速度比较慢的原因。C++的执行效率比Python块很多，这个原因我觉得可以类比到CODE SPECIALIZATION的问题上。

访问方法
存储过程
操作员执行
谓词评估
记录操作

这样做的好处是

属性类型是先验已知的。
- 数据访问函数调用可以转换为内联指针转换。
- 即，可以直接通过offset访问元组中的某个属性。
谓词是先验已知的。
- 可以使用原始数据直接比较来评估它们。
循环中没有函数调用
- 允许编译器高效地将数据分发到寄存器并增加缓存重用。
- 因为没有函数调用，所以只需要直接比较内存块的几个offset的某个size的数据的关系即可。