此文章主要向大家讲述的是DB2 常见问题解答汇总，如果你对DB2 常见问题解答有兴趣的话，你就可以对以下的文章点击观看了，以下就是具体方案的描述，希望在你今后的学习中会有所帮助。
问题 1：SORT 的奥秘
在我的上一个专栏的示例 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 常见问题解答汇集的描述，希望会给你带来一些帮助在此方面。
【编辑推荐】
