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

核心提示：神秘的 PLAN_TABLE 信息在我早期使用 DB2 的时候，我专注于应用程序的性能，“仅索引” 更新和删除的秘密，那时候查找性能问题的工具比较少，其中之一是 EXPLAIN，并且匹配该索引的第一个列（MATCHCOLS = 1），正如 DELETE 预期的那样，我专门学习了 PLAN_TABLE 中列的含义，随着时

神秘的 PLAN_TABLE 信息

在我早期使用 DB2 的时候，我专注于应用程序的性能。那时候查找性能问题的工具比较少，其中之一是 EXPLAIN，我专门学习了 PLAN_TABLE 中列的含义。随着时间的推移，我能够将该数据转换成调优 SQL 的有用信息。

奇怪的是，PLAN_TABLE 给我带来的主要收获不是提高 SQL 性能，而是增强了我对 DB2 优化器设计思想的理解。我花费数小时寻找 DB2 优化器选择一个特定路径而不是另一个路径的原因，以及选择的访问路径在运行时会发生什么情况。换句话说，就是如何寻找和使用索引页和表页。

有时，对于单个查询，PLAN_TABLE 中的某些列看上去互相矛盾。这些 “矛盾” 之一（“仅索引” UPDATE/DELETE 的迷惑）是这篇专栏的主题。其它 “矛盾” 是下一个专栏的主题。

“仅索引” UPDATE 和 DELETE

那么，让我们来解决第二个秘密。当被解释的 SQL 语句是 UPDATE 或 DELETE 语句时，PLAN_TABLE 上的 INDEX_ONLY 标记怎么会是 Y 呢？我第一次看到这种情况时非常困惑。对不起，但是确切的讲，UPDATE（必须更改表数据）或 DELETE（必须从表中删除行）怎么可以 “仅索引” 呢？

典型的 DELETE

让我们看一下 DB2 内部的典型 DELETE 发生什么情况。假设我们的 SQL 语句如下：

DELETE　FROM　BIG_TABLE　B　
WHERE　TRANDATE　=　"2008-06-24"　
　　　AND　STATUS　=　"C"　
对这条语句运行 EXPLAIN 时，我们看到 DB2 选择了 TRANDATE、CUSTNAME 上的名为 IX4 的两列索引（PLAN_TABLE 列 ACCESSNAME 被设置为 IX4），并且匹配该索引的第一个列（MATCHCOLS = 1）。正如 DELETE 预期的那样，INDEX_ONLY 列为 N。