“仅索引” 更新和删除的秘密

核心提示： 获取 1700 个 U 锁获取（升级）1700 个 X 锁一次 COMMIT 来释放 1700 个 X 锁，每个获取 U 锁的请求和每个升级 U 锁到 X 锁的请求都需要对 IRLM 地址空间进行跨内存服务调用，“仅索引” 更新和删除的秘密(3)，此时是被告知 no、wait（锁挂起）或 hec

获取 1700 个 U 锁

获取（升级）1700 个 X 锁

一次 COMMIT 来释放 1700 个 X 锁。

每个获取 U 锁的请求和每个升级 U 锁到 X 锁的请求都需要对 IRLM 地址空间进行跨内存服务调用，此时是被告知 no、wait（锁挂起）或 heck、no（超时/死锁）的好机会。

在我们的例子中，将执行 2200 次 GET PAGE 和 2200 次读 I/O，获取 2200 个 U 锁，释放 500 个 U 锁（离开页时每次释放一个），升级 1700 个 U 锁到 X 锁（每次一个）并在 COMMIT 时释放 1700 个 X 锁。我们将执行 4401 次跨内存服务调用，有 3900 次机会被锁管理器告知 no。

“仅索引” DELETE

让我们看一下，DB2 内部的神秘 “仅索引” DELETE 会发生什么情况。假设 SQL 语句不变，但是索引有所不同。我们的 SQL 语句仍然是：

DELETE　FROM　BIG_TABLE　B　
WHERE　TRANDATE　=　"2008-06-24"　
　　　AND　STATUS　=　"C"　

这次运行 EXPLAIN 时，会看到 DB2 选择 TRANDATE、CUSTNAME、STATUS 上的三列索引，并且匹配该索引的第一个列（MATCHCOLS = 1）。与 DELETE 预期的不同，INDEX_ONLY 标志为 Y。

同样，选择的索引不是 CLUSTER 索引并且允许重复。运行时，DB2 将查找索引，找到 TRANDATE 等于 SQL 语句中的日期的相邻索引行。这次，有 400 个这种条件为真的相邻行。因为我们已经从每 CUSTNAME 每 TRANDATE 一行变成每 STATUS（colcard = 2）每 CUSTOMER 每 TRANDATE 一行，所以数目翻倍。这 400 个条目中的每一个都具有一个可变长度的 RID 链，一些只有一个 RID，另一些有一个长度在 2 个 RID 到 150 个 RID 之间的 RID 链。

但是，这是两个路径是性能发生变化的交叉点。虽然我们读取的相邻索引行的数目翻倍（400 而不是 200），但是 DB2 现在可以将 STATUS 上的谓词应用于匹配范围内的索引数据。DB2 扫描匹配范围时在 STATUS 上应用谓词被称为 INDEX SCREENING。只有 1700 个限制的 RID（两个谓词都为真）。