我們今天主要向大家講述的是DB2性能調優之設計並配置你的數據庫，有很多數據庫設計與配置選項能影響到查詢性能。對數據庫設計的更多建議參考“ Planning your Physical Database Design ”最佳實踐文章。
DB2性能調優之使用約束來提高查詢優化
考慮定義的唯一性，檢查並參考一致性約束。這些約束提供了語義信息，允許 DB2 優化器重寫查詢來評估連接，通過連接來降低聚合和 FETCH FIRST N ROWS，去掉不必要的 DISTINCT 選項被和一些其它的優化。當應用程序可以保證它自己的關系時，信息約束也可以被用來檢查並參考一致性約束。相同的優化也是可以的。
當更新(插入或刪除)行的時候，來自數據庫管理器的強制約束可能導致很高的系統開銷，尤其在更新很多有一致性約束的行的時候。如果一個應用程序在更新一行之前已經驗證的信息，這樣使用信息約束比起正常的約束更有效
例如，考慮 2 個表 DAILY_SALES 和 CUSTOMER 。在 CUSTOMER 表中的每一行都有一個唯一的客戶鍵值(CUST_KEY)。 DAILY_SALES 包含一個 CUST_KEY 列並且每一行都引用一個 CUSTOMER 表中的客戶鍵。可以創建一個參考一致性約束來防止在 CUSTOMER 和 DAILY_SALES 之間發生 1:N 的關系。
如果應用程序要強制約束這個關系，可以創建一個信息化的約束。那麼下面的查詢避免了在 CUSTOMER 和 DAILY_SALES 之間進行連接，因為沒有從 CUSTOMER 獲取任何列，而且來自於 DAILY_SALES 的每一行都可以在 CUSTOMER 裡面找到與之匹配的行，所以查詢優化器將自動刪除連接
- SELECT AMT_SOLD, SALE PRICE, PROD_DESC
- FROM DAILY_SALES, PRODUCT, CUSTOMER
- WHERE
- DAILY_SALES.PROD_KEY = PRODUCT.PRODKEY AND
- DAILY_SALES.CUST_KEY = CUSTOMER.CUST_KEY
應用程序必須執行信息約束，否則查詢可能返回不正確的結果。在上面的例子中，如果行存在於 DAILY_SALES 中，在 CUSTOMER 表中卻找不到相應的客戶鍵，那麼上面的查詢返回的行可能不正確。
DB2性能調優之在復雜查詢中使用 REOPT 綁定選項和輸入變量
在一個在線事務處理(OLTP)環境的中輸入變量有較好的語句准備時間是關鍵，在這樣的環境中語句往往比較簡單而且查詢計劃選擇也很簡單。使用不同的輸入變量多次運行相同的語句可以復用在動態語句高速緩存中編譯了的訪問片段，避免了由於隨時更改輸入值而造成昂貴的 SQL 語句編譯開銷。
然而，輸入變量對復雜的查詢負載也會造成問題，它們的查詢計劃選擇非常復雜，因此優化器需要更多的信息來做出好的決定。而且，語句編譯時間通常是總運行時間中的一個很小組成部分。因為 BI 查詢通常不會重復，所以並沒有從動態語句高速緩存上得到好處。
如果在一個復雜查詢工作負載中需要使用輸入變量，請考慮使用 REOPT(ALWAYS) BIND 選項。當輸入變量值是已知的，REOPT BIND 選項從 PREPARE 到 OPEN 或執行過程中推遲了語句編譯。變量值被傳遞到 SQL 編譯器中，這樣優化器可以使用這些便利來計算一個更精確的選擇評估。
REOPT(ALWAYS) 表示所有執行語句都應該被預編譯。 REOPT(ALWAYS) 也可以被用於涉及特殊寄存器的復雜查詢，比如 "WHERE TRANS_DATE = CURRENT DATE - 30 DAYS" 。如果輸入變量對 OLTP 工作負載造成較差的訪問計劃選擇，並且 REOPT(ALWAYS) 選項因為語句編譯造成過多的開銷，那麼考慮對挑選過的查詢使用 REOPT(ONCE) 。
REOPT(ONCE) 推遲語句的編譯直到首個數據變量被綁定。使用這個首個輸入變量值編譯並優化 SQL 語句。後續使用不同的值來運行的語句將重用基於第一個輸入編譯的查詢片段。這是一個好方法 , 如果首個輸入變量代表了後續的輸入值，並且在輸入值未知的情況下比起優化器使用不同的值進行評估，它提供個了一個更好的查詢訪問計劃
