本文详细介绍了数据库查询处理的步骤，包括查询优化和执行。强调了执行代价的度量，如寻道次数和磁盘传输块数。在选择运算部分，讨论了等值条件、范围条件、合取和析取等情况下的索引使用策略。排序部分，重点阐述了外部归并排序算法及其代价。连接运算部分，讲解了嵌套循环连接、块嵌套循环连接、等值连接的各种优化方法，如索引嵌套循环连接、归并连接和散列连接。
查询处理概述
查询处理的步骤如下：
查询处理可以大概分为三个部分：
- 语法分析与翻译
- 查询优化
- 查询执行
执行代价的度量
设计查询执行方案之前，我们必须能度量一个查询执行方案的代价
在大型数据库系统中，在磁盘上存取数据的代价是查询执行的主要代价，因为比起内存操作，磁盘存取速度很慢
代码在 CPU 中执行也需要时间，但只要 CPU 的运算次数不算太多，CPU 时间相比于 I/O 耗时就可以忽略
在磁盘上存取数据可以分为寻道和数据传输两个步骤，因此我们可以用寻道的次数和传输的块数来度量一个执行方案的代价，我们用 t s t_s ts 表示一次寻道所需的时间， t r t_r tr 表示传输一个块所需的时间， t s t_s ts 的典型值为 4 毫秒， t r t_r tr 的典型值为 0.1 毫秒
选择运算
通用方案
最通用也是最简单的执行选择运算的方案就是：扫描整个关系，对于扫描到的每一个元组，检查它是否满足选择条件
假设一个关系有 B B B 个块，由于整个关系都要扫描，因此磁盘传输的块数为 B B B ，通常情况下，我们可以认为一个关系保存在一个文件中，关系的每个块在物理地址上是大致连续的，因此我们只需要在扫描开始的时候寻道一次
等值条件
当选择条件仅为在某个属性或属性集上取特定的值时，我们可能有比扫描整个关系更快的方案
主索引
若关系在对应属性或属性集上有主索引，那么选择的效率会大大提升，借助主索引，可以定位到所有满足等值条件的元组，并且在这种情况下，这些元组一定存储在文件的连续的块中，假设这些元组存放在文件中连续的 b b b 个块上，检索一次索引需要的块访问次数为 h h h ，则磁盘传输的块数为 b + h b+h b+h ，寻道次数为 h + 1 h+1 h+1 ，通常情况下 h h h 不会很大，相比于扫描整个关系，该方案主要减少了磁盘传输的块数
当然，如果关系在对应属性或属性集上仅组织成顺序文件，而没有创建索引，也可以用二分搜索代替主索引定位满足等值条件的元组
辅助索引
若关系在对应属性或属性集上有辅助索引，则显然要考虑如何利用辅助索引，和主索引不同，利用辅助索引虽然也可以定位到所有满足等值条件的元组，但这些元组可能分布在文件的各个块中，假设共有 n n n 个元组满足选择条件，检索一次索引需要的块访问次数为 h h h ，则在最坏的情况下，这 n n n 个元组所在的块各不相同，需要磁盘传输 n + h n+h n+h 块，每传输一个块，就可能需要一次寻道，最坏情况下需要寻道 n + h n+h n+h 次
从上面的分析可以看出，如果满足等值条件的元组比较少，那么使用辅助索引就是值得的，否则使用辅助索引甚至还不如扫描整个关系的方案
范围条件
类似于等值条件，当选择条件为在某个属性或属性集上取特定范围内的值时，也可以利用索引提升效率
主索引
如果关系在对应属性或属性集上有主索引，或虽然没有索引，但按顺序组织成了顺序文件，都可以做到和等值条件类似的加速，利用索引或二分搜索直接定位到范围的下届，然后按顺序扫描之后的元组，假设满足范围条件的元组有存放在文件中连续的 b b b 个块上，检索一次索引需要的块访问次数为 h h h ，则磁盘传输的块数为 b + h b+h b+h ，寻道次数为 h + 1 h+1 h+1
辅助索引
如果关系在对应属性或属性集上有辅助索引，可以利用它直接定位所有满足范围条件的元组，设满足条件的元组数为 n n n ，检索一次索引需要的块访问次数为 h h h ，最坏情况下需要磁盘传输 n + h n+h n+h 个块，寻道 n + h n+h n+h 次
和等值条件一样，只有在满足范围条件的元组较少的情况下，使用辅助索引才能加速选择运算
合取
实际应用中，选择条件不一定只有一个，可能会由若干个条件组成一个复合条件，当一个复合条件是若干个等值条件或范围条件的合取时，可以考虑利用索引进行加速
一维索引
一维索引是指以单个属性作为搜索码的索引，若当前的选择条件是若干个等值条件或范围条件的合取，假设其中某一个条件 θ \theta θ 对应的属性为 a a a ，并且关系上有一个属性 a a a 上的一维索引，则我们可以借助该索引筛选出满足条件 θ \theta θ 的全部元组，每筛选出一个满足条件 θ \theta θ 的元组，我们再检测其是否满足其它条件
执行该方案的代价约等于借助索引筛选出满足条件 θ \theta θ 的全部元组的代价，如果有多个一维索引满足条件，则优化器在制定执行计划之前需要先估算使用哪个一维索引筛选元组代价更小
高维索引
虽然我们之前讨论的 B+ 树索引和散列索引都是一维索引，但高维索引也是存在的，设 a 1 , a 2 , ⋯ , a n a_1,a_2, \cdots ,a_n a1,a2,⋯,an 是组成复合条件的若干个等值条件或范围条件所对应的全部属性，若关系上存在一个在属性集 a 1 , a 2 , ⋯ , a n a_1,a_2, \cdots ,a_n a1,a2,⋯,an 上的高维索引，则可以借助该高维索引直接定位满足所有等值条件和范围条件的元组
多个一维索引
如果组成复合条件的等值条件或范围条件中，绝大部分条件对应的属性上有一维索引，则可以分别利用这些索引，找到指向满足对应条件的元组的指针集合，再对所有的指针集合求交
对指针集合求交很简单，只需要对所有指针集合中的所有指针排序，然后只保留出现次数等于指针集合数的那些指针
如果组成复合条件的所有条件对应的属性上都有索引，那么运算至此就执行完毕了，但如果还有少部分条件对应的属性上没有索引，我们还需要访问我们刚刚求交得到的所有指针，检测其指向的元组是否满足剩下的少部分条件，由于在求交的过程中我们就给所有指针排好序了，因此我们访问指针的顺序和它们指向的元组在文件中的顺序一致
析取
当一个复合条件是若干个等值条件或范围条件的析取，也可以考虑用索引进行加速
多个一维索引
只有组成复合条件的所有条件对应的属性上有一维索引，我们才有可能借助索引加速，分别利用这些索引，找到指向满足对应条件的元组的指针集合，再对指针集合求并即可
指针集合求并也很简单，只需要给所有集合中的所有指针排序并去重
设 θ 1 , θ 2 , ⋯ , θ n \theta_1 , \theta_2, \cdots , \theta_n θ1,θ2,⋯,θn 表示组成复合条件的所有条件， m 1 , m 2 , ⋯ , m n m_1,m_2, \cdots ,m_n m1,m2,⋯,mn 分别表示满足 θ 1 , θ 2 , ⋯ , θ n \theta_1 , \theta_2, \cdots , \theta_n θ1,θ
最低0.47元/天 解锁文章
4272
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
