詳細講解DB2資料庫效能理解的主要誤區

1、邏輯設計應該總是能和物理設計完全對映實際：db2資料庫設計中物理設計應該盡可能的和邏輯結構相近，但是為效能做出的物理設計改變不能被忽略，因為它們並不來自於邏輯設計。

2、將所有東西放在乙個緩衝池(bp0)中讓db2管理實際：就像在db2手冊和其他地方說明的一樣，你只能在你的記憶體非常受限的情況下(100004kpages或者更少)，你沒有時間去管理它，你也沒有考慮到效能的條件下，去這樣做。最好這樣說：不要放置除了db2catalog和目錄以外的東西進入bp0。

3、dsndb07是100%順序的實際：dsndb07從來就不是100%順序的，因為有工作檔案中的對頁面進行的隨機活動。隨即活動可能高達45%，但是通常範圍是3%到10%。

4、varchar應該總是被放置在行末實際：這就是總是引發問題的話。如果表總是被讀，並且非常少的更新，那麼可以，這將會減少cpu負載，但是在其它情況下這樣做就是最壞的，甚至如果表是被壓縮的。只有在頻繁更新的情況下它應該被放置在末尾，但是並不通常這樣。

5、程式應該以遵循邏輯過程的方式編碼實際：偽**或者乙個邏輯過程圖並不需要考慮效能相關的編碼方式。在oltp交易**中這非常具有戲劇性。

6、大多數過程不在sql中進行實際：事實上，問題的反面往往是正確的。sql是乙個非常豐富的語言，能夠處理大多數過程。實際上最大的困難是sql經常被用來作為i/o處理器而不是乙個集合處理器。

7、**和引用表應該和db2宣告的referentialintegrity(ri)一起使用實際：ri不應該作為乙個編輯有效性的快捷方式而使用，這通常屬於別的什麼，但是應該在真父子關係中使用。

8、表至多有一到兩個索引實際：表應該按照效能需求擁有多個索引。

9、非分割索引(npi)不應該被使用，尤其是不應該在大的表中使用實際：這關係到數不清的問題，總體上這些都能被克服，但是npi是對適當的訪問和效能非常必要的。

10、大表應該被分割實際：因為乙個表中有太多資料就意味著有效能下降，這是乙個遺留的擔心。當一些表中有超過60億行資料時，這個理解已經被消除了。

11、db2預設就是好的實際：預設的一般不是最好的，他們因版本不同而改變。比如考慮繫結引數currentdata。

12、不要在sqlwhere謂詞裡使用否定實際：另外乙個這種規則並沒有被解釋清楚。只有謂詞是乙個否定時，sql訪問路徑可能使用乙個不必要的表空間掃瞄。但是在其它的多數情況下，多餘的過濾應該在db2引擎裡完成，這會較好。