db2預設的優化器級別為5，級別越高優化程度越高，大多數情況下為應用程式繫結時指定高階別的優化器會提高效能，但有時因機器硬體或記憶體分配不合適，高階別的優化會消耗更多的資源，有時會優化報錯。本人碰到過幾次因優化器不能正常工作反而使sql的效能急劇下降的案例。
優化級別 n=0,1,2,3,5,7,9
可以在編譯 sql 查詢時指定下列其中乙個優化器級別：
0 -
此級別指導優化器使用最少的優化來生成訪問方案。此優化級別具有下列特徵：
優化器不考慮任何非均勻分布統計資訊。
僅應用基本的查詢重寫規則。
發生貪婪聯合列舉。
僅允許使用巢狀迴圈連線及索引掃瞄訪問方法。
[9] 在生成的訪問方法中不使用列表預取。
不考慮星型連線策略。
此級別應該只用於需要最低的查詢編譯開銷的情況。查詢優化級別 0 適用於以下應用程式：完全由訪問經過良好索引表的很簡單的動態 sql 語句組成。
1 -
此優化級別具有下列特徵：
優化器不考慮任何非均勻分布統計資訊。
只應用查詢重寫規則的乙個子集。
發生貪婪聯合列舉。
[9] 在生成的訪問方法中不使用列表預取。
除了「合併掃瞄」連線及表掃瞄也可用以外，優化級別 1 類似於級別 0。
2 -
此級別指導優化器使用比級別 1 顯著高的優化程度，而使複雜查詢的編譯成本顯著低於級別 3 及更高階別。此優化級別具有下列特徵：
利用了所有可用的統計資訊，包括頻率和分位數非均勻分布統計資訊。
除只在極少情況下才適用的計算密集型規則外，將應用所有其它查詢重寫規則，包括路由對具體查詢表的查詢。
使用了貪婪聯合列舉。
考慮各種訪問方法，包括列表預取和具體查詢表路由。
如果適用的話，考慮星型連線策略。
優化級別 2 除了使用「貪婪」聯合列舉而不是「動態規劃」以外，類似於級別 5。在所有使用「貪婪」聯合列舉演算法的級別中，此級別具有最高的優化程度，與級別 3 及更高階別相比，它對複雜查詢的替代方案考慮較少，因而消耗的編譯時間也少。建議將級別 2 用於決策支援或聯機分析處理（olap）環境中非常複雜的查詢。在這種環境下，特定查詢很少完全重複，因此查詢訪問方案不大可能在快取記憶體中停留到出現下乙個查詢為止。
3 -
此級別請求中等優化。此級別與 db2 mvs/esa 版、os/390 或 z/os 版的查詢優化特徵基本匹配。此優化級別具有下列特徵：
使用非均勻分布統計資訊（如果可用的話），該統計資訊跟蹤頻繁出現的值。
應用大部分查詢重寫規則，包括子查詢至連線的變換。
動態規劃連線列舉，如下所示：
組合內部表的有限使用
涉及查詢表的星型模式的笛卡爾乘積的有限使用
考慮各種訪問方法，包括列表預取、索引 and 運算和星型連線。
此級別適用於大量應用程式。此級別改進具有 4 個或更多連線的查詢的訪問方案。但是，優化器可能無法考慮使用預設優化級別選擇的更好方案。
5 -
此級別指導優化器使用相當大量的優化來生成訪問方案。此優化級別具有下列特徵：
使用所有可用的統計資訊，包括頻率和分位數分布統計資訊。
除只在極少情況下才適用的那些計算密集型規則外，將應用所有其它查詢重寫規則，包括路由對具體查詢表的查詢。
動態規劃連線列舉，如下所示：
組合內部表的有限使用
涉及查詢表的星型模式的笛卡爾乘積的有限使用
考慮各種訪問方法，包括列表預取、索引 and 運算和具體查詢表路由。
當優化器檢測到不能保證用於複雜動態 sql 查詢的附加資源和處理時間時，將減少優化。減少的範圍或大小取決於機器大小和謂詞數目。
當查詢優化器減少查詢優化量時，它繼續應用正常時應用的所有查詢重寫規則。但是，它的確使用了貪婪聯合列舉法並減少了考慮的訪問方案的組合數。
對於由事務和複雜查詢組成的混合環境，查詢優化級別 5 是乙個很好的選擇。此優化級別設計成可以用高效的方式應用最有價值的查詢變換和其它查詢優化技術。
7 -
此級別指導優化器使用相當大量的優化來生成訪問方案。級別 7 除了不減少用於複雜動態 sql 查詢的查詢優化量以外，它與查詢優化級別 5 是相同的。
9 -
此級別指導優化器使用所有可用的優化技術。這些技術包括：
所有可用的統計資訊
所有查詢重寫規則
聯合列舉的所有可能性，包括笛卡爾乘積和任意多種組合的內部結構
所有訪問方法
此級別可以大大擴充套件由優化器考慮的可能的訪問方案數量。對於使用大表的很複雜且執行時間很長的查詢，可以使用此級別來確定更全面優化是否將生成更好的訪問方案。使用「說明」和效能測量來驗證是否實際上已找到更好的方案。
調整優化器級別案例：
1、中試所fmis3上線後發現業務模組效能很慢，在調優過程中發現大部分複雜的sql都報警告：
sql0437w 此復合查詢的效能可能不是最優的。原因碼為："3"。 sqlstate=01602
經查幫助得知原因：3 優化器成本下溢
估計是伺服器的資源所限(cpu、記憶體)，降低優化級別，調整資料庫引數(dft_queryopt = 3)後問題解決。
$ db2 update db cfg for cwgl using dft_queryopt 3
db20000i the update database configuration command completed successfully. $
2、乙個修正資料的指令碼，含有大量的複雜sql如join、union、group等操作，在執行時同樣報sql0437w的警告，經降低優化器級別後，問題解決。
d:/>db2 -z test.log -std@ -f test.sql
sql0437w 此復合查詢的效能可能不是最優的。原因碼為："3"。 sqlstate=01602
d:/>db2 ? 01602
sqlstate 01602: 優化級別已降低。
d:/>db2set current query optimization=3
db20000i sql 命令成功完成。
d:/>db2 -z test.log -std@ -f test.sql
sql0437w 此復合查詢的效能可能不是最優的。原因碼為："3"。 sqlstate=01602
d:/>db2set current query optimization=2
db20000i sql 命令成功完成。
d:/>db2 -z test.log -std@ -f test.sql
sql0437w 此復合查詢的效能可能不是最優的。原因碼為："3"。 sqlstate=01602
d:/>db2set current query optimization=1
db20000i sql 命令成功完成。
d:/>db2 -z test.log -std@ -f test.sql
db20000i sql 命令成功完成。
d:/>
DB2使用db2advis工具調優SQL
在之前的博文中說了如何去檢視sql的訪問計畫，當我們發現當前計畫需要調整或者想看看有無優化空間時，我們可以使用db2advis工具，該工具是針對使用者提供的工作負載 這裡的工作負載就是一組sql語句的組合 而給出的優化建議，優化建議包括建立索引，mqt，mdc以及表重分布等，優化建議以ddl的形式提...
db2巢狀查詢效率 DB2資料庫SQL優化方法一列
optimize for 子句宣告只想檢索部分結果或者優先檢索前幾行,優化器可以選擇能夠將檢索前幾行所需的響應時間縮至最短的訪問方案。此外，作為單個塊傳送到客戶機的行數由 n 的值限制。因此，optimize for 子句既影響伺服器從資料庫檢索合格行的方式，又影響將那些行返回給客戶機的方式.例如，...
高效能之DB2效能調整和優化
db2效能調整和優化 1.效能優化應該是跨越應用系統的整個生命週期，不是使用者感覺效能差的時候開始 2.對任何程式而言，最慢最耗時間的操作是從磁碟度數 磁碟的轉數沒有較大提高 任何乙個資料庫系統 必然存在大量的 i o，所以 i o是導致資料庫效能問題的關鍵。3.db 中資料訪問都要經過緩衝池 讀的...