經常的執行"RUNSTATS"命令，用來更新DB2的目錄統計，這樣可以在特別繁忙的生產環境里中得到全貌。為了使執行"RUNSTATS"命令的影響最小化，可以考慮使用采樣技術。即使取樣10%也夠了。另外"RUNSTATS"命令可以更新統計，DB2給您可以額外更新1,000個條目的能力，以用于不均勻的分類統計。當心隨著每一條目隨著增量的增加，而涉及到對所有參考的綁定時間的影響。
假如當您缺少統計的時候您怎么知道呢?當目錄或使用工具不能提供這種功能的時候，您可以通過手工執行查詢。當前,DB2優化器不能給缺失的統計提供具體的警告。
技巧2:盡可能的采用階段1和階段2的謂詞:
不論是階段1的數據管理器還是階段2的關系型數據服務器都將處理每一次查詢。當您處理查詢時，使用階段1將會比使用階段2有著巨大的性能優勢。當謂詞確定階段1能夠處理的時候，通常謂詞會限制您只能使用階段1查詢。另外,每一個謂詞都會被檢驗評估是否比另一個謂詞更有資袼作為索引路徑。有一些謂詞不能作為階段1來處理，或是不符合索引的條件。關于您的查詢是否可以被索引并且能夠在階段1被處理，理解這一點是很重要的。下面是文擋化的階段1或Sargable(search+argument-able謂詞是一個可以由數據管理器來值的謂詞)謂詞：
圖3：通常用表單來確定謂詞是否合格
還有一些謂詞不能看作階段1被文檔化，因為他們不能總處于階段1。加入表序列和查詢重寫也能夠影響謂詞被過濾掉的階段。讓我們通過例子查詢來顯示重寫您的SQL的影響。
例子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合并,重新綁定的事務也許可能獲得匹配的索引訪問,那里的舊謂詞將不會對重新綁定有影響。
