例子1:COL1和COL1之間的值:
任何類型的謂詞如不能被階段1識別，就是階段2。如下所示就是階段2謂詞。然而,重寫可能促進對可索引階段1的查詢:Value>=COL1ANDvalue<=COL2。
這意味著,優化器也許會在多個索引中選擇一個匹配的索引來使用謂詞。沒有重寫,謂詞的剩余被當作階段2。
例子2:COL3NOTIN(K,S,T)：
如果可能，非可索引的階段1的謂詞也應該被重寫。例如，符合以上條件的是階段1，但不是可索引的。括號里值的列表辨認什么與COL3不相等。為了確定重寫的可行性，辨認出那些COL3不相等的、更長和更不穩定的表單，就越不具有可行性。如果對面的(K,S,T)是少于200的靜態值,就值得輸入額外的重寫。促進階段1的條件對于可索引的階段1，提供了其它匹配索引選擇的優化器。既使一個可支持的索引在綁定時間不可利用,重寫也將確保查詢具有索引訪問的資格，并且此索引將在以后被創建。一旦一個索引被創建并與COL3合并,重新綁定的事務也許可能獲得匹配的索引訪問,那里的舊謂詞將不會對重新綁定有影響。
技巧3:僅選擇需要的列：
每一個被選擇的列必須單獨地被傳回到調用程序，除非對整個的DCLGEN定義有精確匹配的。這也可能依賴于您向所有列發出的請求，但是，真正的損失發生在需要排序的時候。每一個被SELECTed的列,和重復的排序列，使得排序文件的寬度更寬。文件越長越寬,排序越慢。例如，100,000個四字節的列可能在大約一秒的時間內完成排序。而只有10,000個五十字節的列可能在同樣時間內完成排序。實際的時間是非常依賴于硬件的。
這個規則的例外是“DisallowSELECT*”，當幾個處理需要一個表中行的不同的部分的時候。通過事務的整合,一次取回所有行,然后單獨處理這些部分。
技巧4:選擇唯一需要的行：
越少的行被檢索,查詢將運行的越快。符合要求的行不得不令自己在存儲器中通過漫長之旅,穿過緩沖池,階段1,階段2,可能的分類和轉換，然后傳遞結果集到調用程序。數據庫管理器管理所有的數據過濾；這對于檢索一行是非常浪費的，測試在程序代碼里的那一行，然后過濾掉那行。禁止程序自動過濾是一個必須強制執行的鐵的規則。開發商可能選擇使用程序代碼執行所有或部分的數據操作或者他們可能選擇使用SQL。典型地是混合在一起。已知的敘述顯示，過濾器可能被放入DB2engine里的程序代碼，類似:
|
技巧5:使用常量和字面值，如果值在以后的3年中不改變(對于靜態查詢)：
DB2優化器對所有不均勻的分類統計都充分的使用,并為任何一個列統計提供了不同領域范圍內的值，尤其當沒有主機變量在謂詞中被發現時,(WHERECOL5>'X')。主機變量的目的是使一個事務能適應一個可變化的變量；當一個用戶請求輸入這個值的時候是最經常被使用的。主機變量不需要重新綁定一個程序，當這個變量每一次改變的時候。這種可延伸性能得到優化器準確的耗費。當主機變量剛被發現,(WHERECOL5>:hv5),優化器使用以下的圖表來評估過濾器要素,而不是使用目錄統計：
列的基數性越高,則謂詞的過濾器要素就越低(保留部分行的預測)。多數時候，這種評估有助于優化器對適當存取路徑的選取。然而,有時謂詞的過濾器要素遠離實際。這就是通常需要對存
