技巧3:僅選擇需要的列：

　　每一個被選擇的列必須單獨地被傳回到調用程序，除非對整個的DCLGEN定義有精確匹配的。這也可能依賴于您向所有列發出的請求，但是，真正的損失發生在需要排序的時候。每一個被SELECTed的列,和重復的排序列，使得排序文件的寬度更寬。文件越長越寬,排序越慢。例如，100,000個四字節的列可能在大約一秒的時間內完成排序。而只有10,000個五十字節的列可能在同樣時間內完成排序。實際的時間是非常依賴于硬件的。

　　這個規則的例外是“DisallowSELECT*”，當幾個處理需要一個表中行的不同的部分的時候。通過事務的整合,一次取回所有行,然后單獨處理這些部分。

　　技巧4:選擇唯一需要的行：

　　越少的行被檢索,查詢將運行的越快。符合要求的行不得不令自己在存儲器中通過漫長之旅,穿過緩沖池,階段1,階段2,可能的分類和轉換，然后傳遞結果集到調用程序。數據庫管理器管理所有的數據過濾;這對于檢索一行是非常浪費的，測試在程序代碼里的那一行，然后過濾掉那行。禁止程序自動過濾是一個必須強制執行的鐵的規則。開發商可能選擇使用程序代碼執行所有或部分的數據操作或者他們可能選擇使用SQL。典型地是混合在一起。已知的敘述顯示，過濾器可能被放入DB2engine里的程序代碼，類似:

　　IFTABLE-COL4>:VALUE

　　GETNEXTRESULTROW

　　技巧5:使用常量和字面值，如果值在以后的3年中不改變(對于靜態查詢)：

　　DB2優化器對所有不均勻的分類統計都充分的使用,并為任何一個列統計提供了不同領域范圍內的值，尤其當沒有主機變量在謂詞中被發現時,(WHERECOL5>'X')。主機變量的目的是使一個事務能適應一個可變化的變量;當一個用戶請求輸入這個值的時候是最經常被使用的。主機變量不需要重新綁定一個程序，當這個變量每一次改變的時候。這種可延伸性能得到優化器準確的耗費。當主機變量剛被發現,(WHERECOL5>:hv5),優化器使用以下的圖表來評估過濾器要素,而不是使用目錄統計：

　　圖4：過濾器要素

　　列的基數性越高,則謂詞的過濾器要素就越低(保留部分行的預測)。多數時候，這種評估有助于優化器對適當存取路徑的選取。然而,有時謂詞的過濾器要素遠離實際。這就是通常需要對存取路徑進行調優的時候。