以下的文章主要向大家講述的是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 常見問題解答匯集的描述，希望會給你帶來一些幫助在此方面。
