以下的文章主要描述的是全面解析DB2性能調(diào)優(yōu)方面的12個(gè)疑難問題，假如你在實(shí)際操作中遇到相似的情況，但是你卻不知道對(duì)其如何正確的解決，那么以下的文章對(duì)你而言一定是良師益友。

1、邏輯設(shè)計(jì)應(yīng)該總是能和物理設(shè)計(jì)完全映射

實(shí)際：DB2數(shù)據(jù)庫設(shè)計(jì)中物理設(shè)計(jì)應(yīng)該盡可能的和邏輯結(jié)構(gòu)相近，但是為性能做出的物理設(shè)計(jì)改變不能被忽略，因?yàn)樗鼈儾⒉粊碜杂谶壿嬙O(shè)計(jì)。

2、將所有東西放在一個(gè)緩沖池(BP0)中讓DB2管理

實(shí)際：就像在DB2手冊(cè)和其他地方說明的一樣，你只能在你的內(nèi)存非常受限的情況下(10000 4k pages或者更少)，你沒有時(shí)間去管理它，你也沒有考慮到性能的條件下，去這樣做。***這樣說：不要放置除了DB2 catalog和目錄以外的東西進(jìn)入BP0。

3、DSNDB07是100%順序的

實(shí)際：DSNDB07從來就不是100%順序的，因?yàn)橛泄ぷ魑募械膶?duì)頁面進(jìn)行的隨機(jī)活動(dòng)。隨即活動(dòng)可能高達(dá)45%，但是通常范圍是3%到10%。

4、VARCHAR應(yīng)該總是被放置在行末

實(shí)際：這就是總是引發(fā)問題的話。如果表總是被讀，并且非常少的更新，那么可以，這將會(huì)減少CPU負(fù)載，但是在其它情況下這樣做就是最壞的，甚至如果表是被壓縮的。只有在頻繁更新的情況下它應(yīng)該被放置在末尾，但是并不通常這樣。

5、程序應(yīng)該以遵循邏輯過程的方式編碼

實(shí)際：偽代碼或者一個(gè)邏輯過程圖并不需要考慮DB2性能調(diào)優(yōu)相關(guān)的編碼方式。在OLTP交易代碼中這非常具有戲劇性。

6、大多數(shù)過程不在SQL中進(jìn)行

實(shí)際：事實(shí)上，問題的反面往往是正確的。SQL是一個(gè)非常豐富的語言，能夠處理大多數(shù)過程。實(shí)際上***的困難是SQL經(jīng)常被用來作為I/O處理器而不是一個(gè)集合處理器。

7、代碼和引用表應(yīng)該和DB2聲明的referential integrity(RI)一起使用

實(shí)際：RI不應(yīng)該作為一個(gè)編輯有效性的快捷方式而使用，這通常屬于別的什么，但是應(yīng)該在真父子關(guān)系中使用。

8、表至多有一到兩個(gè)索引

實(shí)際：表應(yīng)該按照性能需求擁有多個(gè)索引。

9、非分割索引(NPI)不應(yīng)該被使用，尤其是不應(yīng)該在大的表中使用

實(shí)際：這關(guān)系到數(shù)不清的問題，總體上這些都能被克服，但是NPI是對(duì)適當(dāng)?shù)脑L問和性能非常必要的。

10、大表應(yīng)該被分割

實(shí)際：因?yàn)橐粋€(gè)表中有太多數(shù)據(jù)就意味著有性能下降，這是一個(gè)遺留的擔(dān)心。當(dāng)一些表中有超過60億行數(shù)據(jù)時(shí)，這個(gè)理解已經(jīng)被消除了。

11、DB2缺省就是好的

實(shí)際：缺省的一般不是***的，他們因版本不同而改變。比如考慮綁定參數(shù)CURRENTDATA。

12、不要在SQL WHERE謂詞里使用否定

實(shí)際：另外一個(gè)這種規(guī)則并沒有被解釋清楚。只有謂詞是一個(gè)否定時(shí)，SQL訪問路徑可能使用一個(gè)不必要的表空間掃描。但是在其它的多數(shù)情況下，多余的過濾應(yīng)該在DB2引擎里完成，這會(huì)較好。以上的相關(guān)內(nèi)容就是對(duì)全面解析DB2性能調(diào)優(yōu)方面的二十個(gè)疑難問題的介紹，望你能有所收獲。

【編輯推薦】

1. IBM DB2數(shù)據(jù)庫SQL編碼優(yōu)化的基礎(chǔ)教程經(jīng)典版！
2. DB2數(shù)據(jù)庫物化視圖之MQT物化查詢表的正確應(yīng)用
3. 如何正確的對(duì)DB2dart恢復(fù)數(shù)據(jù)進(jìn)行操作？
4. IBM DB2跨平臺(tái)數(shù)據(jù)庫遷移操作步驟與注意點(diǎn)！
5. 實(shí)現(xiàn)DB2數(shù)據(jù)庫遷移之導(dǎo)入步驟在Linux下