深入理解DB2索引（Index）

转载自:http://blog.csdn.net/idber/article/details/8096941

索引（Index）是数据库管理系统中一个非常重要的数据结构，索引的合理使用能够极大提高数据库系统的性能。那么，什么是索引？索引有时如何提高数据库系统性能的呢？

阅读本文时建议参考：《深入理解数据库磁盘存储（Disk Storage）》

索引概念

以一本书为例，通常一本书开头会有目录，而后才是正文，通过目录中每行左侧的标题和右侧的页码，我们可以快速定位到需要阅读的页面，而无需一页一页翻阅到该页面。数据库中的索引就像目录，它能帮助数据库管理系统快速定位到表中符合查询条件的数据行。索引实际上也是数据表的组成部分之一（数据表的存储包括数据页面+索引页面）

定义：数据库索引实际上是一个单独的、物理的数据库结构，它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针的清单（序列）。

从索引的定义中可以得到：

1.索引是一个物理数据结构，也就是说，它是需要保持到物理磁盘上的，和普通的表数据一样要占用磁盘空间，也是存储在数据页上的。

2.索引是一个清单（或者说序列），由两部分组成：数据库表中的一列或多利的列值的集合、指向这些列值的数据页的逻辑指针。

可以把索引看作是一张只有两列的表，一列是普通数据表的列值（key-value），另一列是该列值的行对应的数据页的逻辑指针（Row-Pointer），这个逻辑指针可以理解为就是RID。需要说明的是，根据数据库产品和索引类型的不同，逻辑指针的结构也各不相同。如下图是索引的一个概览性描述，右侧是数据表页，左侧是对应的索引页。还有一点，从图上可以看到，表中的行之间是有指针相连的，即数据页中的每个记录除了存放数据，还会包含一个指针，指向其下一行记录。各记录形成一种链表结构。当然，这种结构并不是所有数据库系统都会采用的。

索引怎样提高性能

考虑这样一种情况：如上图，银行数据库的account表有编号（ID），城市（City）和余额（Balance）三列。表中一共有10万行数据。现在要列出属于Mianus这个城市的所有账号，查询语句为：

Select * From account Where city=‘Mianus’

为了找出满足条件的查询，数据库管理器必须扫描account表中的所有行，逐行匹配，即表扫描。这会向缓冲池调入大量的数据页，执行大量I/O操作无疑是非常影响性能的。

如果在city列建立索引，则DB2查询优化器会在索引中扫描匹配的行，然后根据该行的逻辑指针找到那些满足条件的表数据行并将对应的数据页调入缓冲池，从而大大减少I/O操作。【一般而言，索引是可以常驻缓冲池的，所以对索引的扫描可以无需进行耗时的I/O操作】

当然上面的索引工作机制的描述是直观性的，真正的索引工作机制下文再讨论。

索引的分类–按结构分

索引按照结构可以分为有序索引（ordered index）和散列索引（hash index）两种基本类型。其中有序索引是基于值的顺序排序，根据值的排序进行索引值的查找。而散列索引则是基于将值平均分布到若干散列桶（hash bucket）。根据散列函数确定索引值所在的散列桶。

有序索引

顺序文件索引

有序索引的一种最简单实现形式是顺序文件索引。顺序文件索引结构更加类似一张两列表，所有的索引值顺序排列，进行查询的时候逐行扫描索引中的各行记录，找到匹配项后就能根据逻辑指针找到表数据行的数据页。
那么，是不是建立索引的列的所有列值都必须成为索引中的索引值呢？不是。
稠密索引（dense index）和稀疏索引（sparse index）
稀疏索引，数据行在数据页中必须按照索引记录的顺序而顺序排列才可能有效，否则有的列值就可能找不到或者找不全。但是和稠密索引相比，稀疏索引有着节省存储空间的优势。

多级索引

有时候，即便使用稀疏索引，由于数据量大且索引列上的列值多，索引本身也会变得非常大而难于有效处理（索引过大就难以保证常驻内存，进行磁盘读取的话，索引越大，需要的I/O越多），为了处理这种问题，我们使用了多级索引技术，其思想就是对索引建立索引。以一个二级索引为例，先根据外层索引定位到内层索引相应位置，在根据内层索引定位到表数据的数据页。这样的多级索引结构肯定会使得外层索引中的索引记录会少很多，如何便可以只将外层索引常驻内存从而达到减少I/O的目的了。

当然，无论是哪一级索引，都既可以是稠密索引也可以是稀疏索引（最内层可能只能是稠密索引）。实际上，索引记录本身就是顺序存储的，所以建立在索引上的索引通常是稀疏索引，这样才能更好的发挥多级索引的作用。

B+树索引

顺序文件索引的最大缺点在于，随着表数据行的增大和索引的增大，索引查找性能（多级索引的复杂度，索引扫描量）和数据顺序扫描性能（数据在增删改等操作中会变得非常混乱，难以维护）都会下降。虽然这种性能下降可以通过表重组和索引重组解决，但是频繁的重组同样是我们不愿意看到的。

因此，一种新的索引结构被广泛接受，这就是B+树索引。B+树是B树（平衡查找树，一种多路查找树）的一个重要变种（参考：B 树、B- 树、B+ 树和B* 树），B+树索引结构是使用最广泛，在数据插入和删除的情况下仍能保持其执行效率的几种索引结构之一。目前DB2的索引结构就是B+树索引，Oracle的普通索引结构是B+树索引的变种B*树索引。

B+树索引采用平衡树（balanced tree）结构，其中根结点到每个叶结点的路径长度都是相同的（所有叶结点都在同一层），树中除根结点外，每个非叶结点有[n/2] （这里的[]符号表示取天棚，如[3/2]=2。天棚符号显示不出。下同）到n个子结点，每个页结点有[(n-1)/2]到n-1个索引值（key-value，我们称为搜索码：search key）。一个B+树的例子：其中n=4，索引值（搜索码）是2,3,5,7,11,13,17,19,23,29,31,37,41,43,47.

B+树索引结构

既然DB2的索引是B+树索引，那么B+树索引在磁盘上到底是怎样存储的呢？

前面介绍过，索引和表数据行一样，存储在数据页中。事实上，一个索引数据页就是索引B+树的一个结点！

每个结点在数据页中的存储方式是这样的：

其中P1，P2，…….，Pn是n个指针；K1，K2，……，Kn-1是n-1个搜索码（索引值），这n-1个搜索码是按照从小到大的顺序排列的。

对于非叶结点：

P1指向另一个结点数据页，这个结点数据页中的所有搜索码值都小于K1（按某种排序规则规定的大于小于关系，比如Brighton