以下的文章主要向大家讲述的是DB2 常见问题解答大汇总,以下的文章将会给你相应的解决方案,如果你对DB2 常见问题解答,心存好奇的话,以下的文章将会揭开它的神秘面纱。在我的上一个专栏的示例 4 中(“ The Mystery of DB2 Sorts ”,见参考资料)。
我讨论了如何在下面的 SQL 语句中使用索引:
- Select workdept, lastname, jobcode from employee_master
- Where workdept in ('A01', 'B22', 'B46') and lastname >= :hvlastname
- Order by lastname
文章中写道:
使用第三个索引 [on jobcode, workdept, lastname] 时,DB2 不能匹配任意一个谓词,但它能够通过筛选(而不是匹配)lastname 和 workdept 对索引数据应用谓词。对于符合条件的每个索引行,DB2 可以从该索引本身获取这三个选择的列,从而避免对表进行读操作。因为索引的***列为 lastname,所以数据应该按 lastname 排序。这里不需要使用 SORT 。
接下来您问道,第三个索引的***列不是 lastname 。为什么不使用数据排序就能以 lastname 顺序返回呢?这就是秘密所在之处。
至少有 200 位读者向我反映了这个问题。对我而言,这既是好消息又是坏消息。好消息是很多读者阅读我的专栏,并且读得非常仔细。坏消息是在收到***一封电子邮件时,我感到非常难堪。
事情是这样的。我开始时使用一个完全不同的虚构的 “第三个索引” 和一个新点子,但后来我改变了主意,并对索引进行更改。然后我重复输入了一个已有段落,不小心忘记删除***两个句子(上面用斜体标出的句子)。
那么,我想实现的新点子是什么呢?它就是:当 DB2 选择的访问路径仅为索引时,DB2 将忽略该索引的 CLUSTERRATIO 。对于纯索引访问,DB2 不会关心索引顺序和表顺序之间的关系。 DB2 永远不会以列表预取的方式使用索引。为什么?没有必要执行 RID SORT 使对表的读操作更加有序,因为不会读取这个表。
在这个例子中,DB2 将执行完整的索引空间扫描,使用有序预取读取每个单个的索引行,将这两个谓词应用到每个行,并且对于符合条件的行,将从索引数据中获取所有三个列。数据将不是按照 lastname 进行排序。因此,DB2 必须执行 SORT 来满足 ORDER BY 子句。
现在,我终于算是弥补了自己的过失。以上的相关内容就是对DB2 常见问题解答汇集的介绍,望你能有所收获。
上述的相关内容就是对DB2 常见问题解答汇集的描述,希望会给你带来一些帮助在此方面。
【编辑推荐】