DML操作时索引的更新行为

我们再来看一下做更新时，索引又是如何做的？

执行如下SQL，对以’990’结尾的字符串进行更新，更新后的值为以’997’结尾的字符串。

图 90

由前边对索引根块的分析（请参见图84）可知，更新后的值，也仍然应落在最后一个叶子块上。查看最后一个叶子块中的数据情况：

图 91

如上图所示，从“kdxconro 6”来看，索引条目数仍为6，和更新前是一样的。

图 92

如上图所示，我们发现更新前的值—以’990’结尾的字符串仍存在，并没有变为’997’结尾的字符串，而是被标记上了删除标志D（row#2[6499] flag: —D–）。更新后的新值，是做为一个新的索引条目，被插入到了索引条目中。同时，我们可以发现目前这条索引条目在数据块中的位置，是最靠近数据块顶部的（row#4[4455]）。所以，对于索引的更新操作，实际上是由删除和插入两个操作来组合完成的。

但是，如果我们还有印象的话，在前面观察索引的删除操作时（请见图88），其中一个索引条目是“row#1[7010] flag: —D—”这样的。但在本次更新操作后，我们发现这一个索引条目已经被彻底删除了。也正因为如此，才会有在图91中我们看到的，最后一个叶子块中的索引条目数仍为6的情形。所以，我们可以推测，被标记为删除的索引条目，会在下一次对索引条目做维护操作时，被彻底删除。为了验证这个推测，我们测试执行以下SQL，以便继续在最后一个叶子块发生一次维护操作：

图 93

观察此时最后一个叶子块中的内容：

图 94

如上图所示，我们可以看到“kdxconro 6”没有变。我们看一下原来的“row#2[6499] flag: —D—”是否还在呢？

图 95

如上图所示，原来的row#2中的内容已经消失了。现在已经是原来row#3中的内容了。上述实验，说明我们的推测应该是基本符合实际情形的。

更进一步，如果我们更新后的值与更新前的值不在同一个叶子块上，从我们之前所做的实验来看，应该是在更新前的值所在的叶子块的索引条目上做删除标识，而在更新后所在的叶子块上做插入。下面，我们通过执行以下SQL来验证一下：

图 96

我们先来看一下索引此时的树形结构信息：

图 97

如上图所示，我们可以看到最后一个叶子块（即’995’结尾的字符串所在的叶子块）中的rrow已经是5了。说明有一条索引条目被标识为删除了；而更新的值，即以’009’结尾的字符串。从图84中显示的根块索引条目来看，row#0所指向的叶子块中的最小值是以’07x’结属的字符串。显然新的字符串应该是在第一个叶子块中，即kdxbrlmc中所指向的第一个叶子块中。经过与此前的索引树形结构信息的对比，我们可以看到第一个叶子块中的索引条目已然从13增加到了14，这说明在叶子块中，确实增加了一条索引条目。