DB2 索引存取路徑深度解析：為何 ORDER BY 有時仍需 SORT

案例 SQL 與索引定義

SELECT workdept, lastname, jobcode
FROM employee_master
WHERE workdept IN ('A01','B22','B46')
  AND lastname >= :hvlastname
ORDER BY lastname;

假設存在索引 IX3 (jobcode, workdept, lastname)。

優化器選擇「純索引掃描」時的行為

• DB2 發現三個選擇欄位全在索引中 → Index-Only Access，避免回表。
• 套用謂詞：workdept IN ... 以「篩選」方式評估，lastname >= ? 同樣篩選。
• 因索引首欄為 jobcode，資料實際儲存順序為 jobcode → workdept → lastname，非按 lastname 排序。

關鍵結論：CLUSTERRATIO 在純索引存取中被忽略

當存取路徑為 Index-Only 時，DB2 完全不參考 CLUSTERRATIO，也不會執行 RID SORT 或列表預取。因為不需讀取資料表，索引與表的叢集關係失去意義。

結果：仍需執行 SORT 滿足 ORDER BY

索引掃描產生的資料流順序為 jobcode, workdept, lastname，不符合 ORDER BY lastname，因此优化器必須在索引掃描之上加入 SORT 操作符 重新排序。

修正後的索引建議

若欲避免 SORT，索引首欄應為排序欄位：

CREATE INDEX IX_opt ON employee_master (lastname, workdept, jobcode);

此時索引順序符合 ORDER BY lastname，且仍涵蓋所有選擇欄位與謂詞欄位，可實現 無 SORT 的 Index-Only Scan。

圖解：執行計畫對比

延伸閱讀

• DB2 Index Design Guide: Cluster Ratio vs. Index-Only Access
• Understanding DB2 Sort Avoidance with ORDER BY