DML操作时索引的维护

当我们对表进行DML(增、删、改操作)操作时，已存在的索引是如何同步维护的呢？当我们了解并理解了其工作原理后，在对索引进行管理和维护工作时，就可以避免一些对索引认识的错误，从而导致做了一些无用的，甚至是弊大于利的工作。

首先，我们先创建测试用表和索引，如下所示：

图 80

如上所示，我们创建了一个名为tab_dml表，该表由两列构成。其中c1列做为测试索引的索引列，其数据类型为char(500)。之所以将其设置为该数据类型，目的是用较少的记录数，就可以模拟出多层的索引。

查看此时索引的树形结构，如下所示：

图 81

如上所示，这是一个2层的索引，有1个根块和16个叶子块。其中前15个叶子块中，每个叶子块中有13条索引条目，最后一个叶子块中有5条索引条目。

下面，我们来看一下最后这个叶子块中存储的索引条目的值是什么？

图 82

图 83

如上两图所示（为节省篇幅，内容有所删减），我们可以看到在该叶子块上的5个索引条目中的值，从小到大，依次为’980’、 ’985’、 ’990’、 ’995’和’1000’结属的字符串。后面的实验，也将主要集中在这个叶子块上。

同时，我也将根块中的主要内容展示如下：

图 84

如上图所示，我们可以看到该根块中共有16个指向下一层的指针（kdxbrlmc+row#0到row#14，共16个叶子块）。其中指向最后一个叶子块的索引条目中，显示该叶子块中的最小值是以’98x’结尾的字符串。

插入索引项时的行为

当我们向表中插入新记录时，相应列上的索引，也会由数据库做自动同步维护，以保证索引可以及时和正确的反映表中的数据。下面，我们仍然通过实验，观察索引都同步做了什么？

执行以下INSERT操作后，观察叶子块中的数据的变化情况：

图 85

因为插入的值是’987’结尾的字符串，所以，从索引的树形结构中（请见图81）以及根块中各个索引条目中记录的值（请见图84），可以推测该条记录所对应的c1列上值，会被插入到最后一个叶子块中。因为最后一个叶子块中的最小值是‘98x’结尾的字符串。

我们看一下此时该叶子块中的实际内容：

图 86

图 87

从图86中，我们可以看到“kdxconro 6”字样，说明本叶子块中的索引条目已经增长到6条了。从图87中，我们可以看到以’987’结尾的字符串值，被排到了原来以’985’和’990’结尾的字符串中间了。但是，在数据块中的实际位置，并不是被插到了原来这两条数据中间，而是用堆表插入的方法，不断从底部向顶部使用空间。这一点从“row#”后面的中括号中的数值就可以看出来。中括号中的数值表示该索引条目在数据块内的相对位置。比如“row#0[7521]”就表示插入该索引条目后，其结束于本数据块的第7521字节处。所以，如果我们观察插入前该叶子块中各索引条目的相对位置，我们可以发现先插入的索引条目更靠下（中括号中的值更大），表示更接近数据块的底部，而后插入的索引条目更靠上（中括号中的值更小），表示更接近数据块的顶部。

因此，索引条目中的row#只代表其值大小的逻辑顺序，并不代表其在索引块中的物理位置。即，row#0中索引条目中记录的值，一定小于row#1中索引条目中记录的值，但row#0这条数据在块中的实际物理位置，并不一定是在row#1的下部。所以，我们可以看到我们新插入的记录，被排在了row#2,但其物理位置确是最靠近顶部的。