从辅助索引谈到多表聚类文件组织

  本文是上一篇文章从数据库存储,文件结构谈到B树,散列的续集,主要介绍一下两个概念:辅助索引以及多表聚类文件

 1. 顺序索引和散列索引

  首先比较一下顺序索引和散列索引。顺序索引非常便于范围查询,这个也很好理解,毕竟是顺序的,我们先找到下界,然后顺序,直到遇到下界。而这一点对于散列索引来说就比较困难了,因为各个桶之间没有大小关系。然而散列索引的优点在于查找特定的键值非常方便,在散列中平均查找时间是个很小的常数。

2. 多表聚类文件组织

  既然谈到了范围查询已经键值查询用什么结构比较合适,不妨谈一谈连接操作怎么设计结构比较合适,这就是多表聚类文件组织。如果我们知道某个特定的连接操作是会被经常使用的,那么我们就可以将该操作涉及的表存在一起,

  举个例子,有两个表:

QQ截图20131214221055    QQ截图20131214221101

  我们知道这两个表的连接操作频繁发生,也就是类似于:

QQ截图20131214221124

  那么我们存储的时候就可以将两个表联合在一起存储以便可以一次块的读取操作就可以读取满足连接条件的记录,下面是多表聚类文件的例子:

QQ截图20131214221116

 

 

 3. 辅助索引

  辅助索引,就是使用搜索码之外的其他码作为排序依据,当然了,一般来说辅助索引中一系列的连续指向的记录在物理上不是顺序存放的。也就是因为不是连续存放,导致了辅助索引必须为稠密索引。使用辅助索引的目的在于课以提高搜索码之外的其他码的查询性能,但是数据库更新的时候会增加很多开销。

  下面的例子中辅助索引是按照工资顺序来排序的。

QQ截图20131214220640

  辅助索引的更新存在一个问题,因为有些文件组织(如B+树文件组织),及时记录本身没有更新,记录的位置也可能改变。比如说一个磁盘损坏了,我们将其存储的记录移动到新的磁盘。这个时候更新辅助索引就非常不合适了,因为每个磁盘存储了很多记录,而每个记录可能被分配到每个辅助索引的不同位置,这样一来,更新的代价就太大了,可能会设计的几十次的I/O访问。这个问题怎么解决呢?

  在辅助索引中,我们不再存储指向所有记录的指针,而是存储主索引搜索码的属性值。这样以来的话,即使记录重定位了,也不必更新辅助索引了。当然了,也有弊端,就是每次通过辅助索引访问的时候就需要先找到对应的主索引搜索码值,然后再用主索引来查找。

4. 参考

  database system concepts

原文地址:https://www.cnblogs.com/xubenben/p/3474783.html