深入優(yōu)化DB2 數(shù)據(jù)庫(kù)的五個(gè)最佳實(shí)踐

　　結(jié)構(gòu)化查詢語言(SQL)對(duì)于關(guān)系型DBMS是把雙刃劍，利弊參半。因?yàn)閺年P(guān)系型數(shù)據(jù)庫(kù)檢索任何數(shù)據(jù)都需要SQL，本文所要探討的話題就是：不論是終端用戶還是開發(fā)人員或是數(shù)據(jù)庫(kù)管理員（DBA），他們將如何訪問一個(gè)關(guān)系型數(shù)據(jù)庫(kù)。當(dāng)使用高效的SQL時(shí),系統(tǒng)會(huì)變得易于升級(jí)、靈活、而且便于管理。當(dāng)使用低效的SQL時(shí),響應(yīng)時(shí)間和程序運(yùn)行時(shí)間都會(huì)延長(zhǎng)，并且還會(huì)產(chǎn)生應(yīng)用系統(tǒng)的中斷。鑒于通常的數(shù)據(jù)庫(kù)系統(tǒng)一般要花費(fèi)90%的處理時(shí)間用于從數(shù)據(jù)庫(kù)檢索數(shù)據(jù)，由此很明顯的可以看出盡可能的保證SQL的高效是多么的重要?？疾焱ǔ５腟QL語句問題譬如"SELECT*FROM"僅是冰山一角,我們將在本文中探討其他容易確定的普遍的問題。需要記住的是,檢索得到同一數(shù)據(jù)的SQL語句有很多種殊途同歸的寫法，所以不存在好的查詢語句或是壞的查詢語句，而只有滿足適當(dāng)需求的查詢語句。各關(guān)系型數(shù)據(jù)庫(kù)都有自己的方式來優(yōu)化和執(zhí)行查詢語句。因此，各DBMS都擁有自己的最佳性能的查詢技巧。本文將使用Quest軟件中QuestCentralforDB2的例子和概述來集中討論DB2forOS/390和z/0S。

　　要是在十七年前，這張技巧單會(huì)更長(zhǎng)，并且會(huì)包含對(duì)最小化的SELECT場(chǎng)景的矯正方法。每一個(gè)新版本的DB2都會(huì)增加成千上萬行的新代碼，用以擴(kuò)展智能優(yōu)化，和查詢重寫及執(zhí)行。例如，多年來一種被稱為數(shù)據(jù)管理器的組件,通常被提供作為"第一階段處理"以增加它的過濾容量一百倍。另一組件是關(guān)系型數(shù)據(jù)服務(wù)器，通常被提供作為"第二階段處理"來進(jìn)行其主函數(shù)的查詢重寫和優(yōu)化。另一關(guān)鍵組件就是基于當(dāng)前的SQL，并使用存取路徑以決定檢索數(shù)據(jù)的DB2優(yōu)化器。DB2優(yōu)化器改善了每一個(gè)DB2的版本,考慮到另外的DB2目錄中的統(tǒng)計(jì),可以提供新的和改善過的存取路徑。圖1顯示了這些組件及其他更多的部分，并描述了DB2如何處理數(shù)據(jù)或SQL的請(qǐng)求。這就是以下DB2SQL性能技巧的來源。

　　在這篇文章中，我們將回顧一些更具有代表性的SQL問題，有更多的SQL方面的性能技巧超出了本篇文章描述的范圍。像所有指導(dǎo)方針一樣，所有這些技巧也會(huì)有一些例外。

　　技巧1：核實(shí)是否提供了適當(dāng)?shù)慕y(tǒng)計(jì):

　　對(duì)于DB2優(yōu)化器來說，最重要的資源除了SELECT語句本身，就是DB2目錄中創(chuàng)建的統(tǒng)計(jì)。優(yōu)化器基于眾多的選擇而使用這些統(tǒng)計(jì)。DB2優(yōu)化器為了查詢而選擇一條非最佳存取路徑的主要原因，歸結(jié)于無效的或缺失的統(tǒng)計(jì)。DB2優(yōu)化器使用以下目錄統(tǒng)計(jì):

　　經(jīng)常的執(zhí)行"RUNSTATS"命令，用來更新DB2的目錄統(tǒng)計(jì)，這樣可以在特別繁忙的生產(chǎn)環(huán)境里中得到全貌。為了使執(zhí)行"RUNSTATS"命令的影響最小化，可以考慮使用采樣技術(shù)。即使取樣10%也夠了。另外"RUNSTATS"命令可以更新統(tǒng)計(jì)，DB2給您可以額外更新1,000個(gè)條目的能力，以用于不均勻的分類統(tǒng)計(jì)。當(dāng)心隨著每一條目隨著增量的增加，而涉及到對(duì)所有參考的綁定時(shí)間的影響。

　　假如當(dāng)您缺少統(tǒng)計(jì)的時(shí)候您怎么知道呢?當(dāng)目錄或使用工具不能提供這種功能的時(shí)候，您可以通過手工執(zhí)行查詢。當(dāng)前,DB2優(yōu)化器不能給缺失的統(tǒng)計(jì)提供具體的警告。

　　技巧2:盡可能的采用階段1和階段2的謂詞:

　　不論是階段1的數(shù)據(jù)管理器還是階段2的關(guān)系型數(shù)據(jù)服務(wù)器都將處理每一次查詢。當(dāng)您處理查詢時(shí)，使用階段1將會(huì)比使用階段2有著巨大的性能優(yōu)勢(shì)。當(dāng)謂詞確定階段1能夠處理的時(shí)候，通常謂詞會(huì)限制您只能使用階段1查詢。另外,每一個(gè)謂詞都會(huì)被檢驗(yàn)評(píng)估是否比另一個(gè)謂詞更有資袼作為索引路徑。有一些謂詞不能作為階段1來處理，或是不符合索引的條件。關(guān)于您的查詢是否可以被索引并且能夠在階段1被處理，理解這一點(diǎn)是很重要的。下面是文擋化的階段1或Sargable（search+argument-able謂詞是一個(gè)可以由數(shù)據(jù)管理器來值的謂詞）謂詞：

　　還有一些謂詞不能看作階段1被文檔化，因?yàn)樗麄儾荒芸偺幱陔A段1。加入表序列和查詢重寫也能夠影響謂詞被過濾掉的階段。讓我們通過例子查詢來顯示重寫您的SQL的影響。

　　例子1:COL1和COL1之間的值:

　　任何類型的謂詞如不能被階段1識(shí)別，就是階段2。如下所示就是階段2謂詞。然而,重寫可能促進(jìn)對(duì)可索引階段1的查詢:Value>=COL1ANDvalue<=COL2。

　　這意味著,優(yōu)化器也許會(huì)在多個(gè)索引中選擇一個(gè)匹配的索引來使用謂詞。沒有重寫,謂詞的剩余被當(dāng)作階段2。

　　例子2:COL3NOTIN(K,S,T)：

　　如果可能，非可索引的階段1的謂詞也應(yīng)該被重寫。例如，符合以上條件的是階段1，但不是可索引的。括號(hào)里值的列表辨認(rèn)什么與COL3不相等。為了確定重寫的可行性，辨認(rèn)出那些COL3不相等的、更長(zhǎng)和更不穩(wěn)定的表單，就越不具有可行性。如果對(duì)面的(K,S,T)是少于200的靜態(tài)值,就值得輸入額外的重寫。促進(jìn)階段1的條件對(duì)于可索引的階段1，提供了其它匹配索引選擇的優(yōu)化器。既使一個(gè)可支持的索引在綁定時(shí)間不可利用,重寫也將確保查詢具有索引訪問的資格，并且此索引將在以后被創(chuàng)建。一旦一個(gè)索引被創(chuàng)建并與COL3合并,重新綁定的事務(wù)也許可能獲得匹配的索引訪問,那里的舊謂詞將不會(huì)對(duì)重新綁定有影響。

　　技巧3:僅選擇需要的列：

　　每一個(gè)被選擇的列必須單獨(dú)地被傳回到調(diào)用程序，除非對(duì)整個(gè)的DCLGEN定義有精確匹配的。這也可能依賴于您向所有列發(fā)出的請(qǐng)求，但是，真正的損失發(fā)生在需要排序的時(shí)候。每一個(gè)被SELECTed的列,和重復(fù)的排序列，使得排序文件的寬度更寬。文件越長(zhǎng)越寬,排序越慢。例如，100,000個(gè)四字節(jié)的列可能在大約一秒的時(shí)間內(nèi)完成排序。而只有10,000個(gè)五十字節(jié)的列可能在同樣時(shí)間內(nèi)完成排序。實(shí)際的時(shí)間是非常依賴于硬件的。

　　這個(gè)規(guī)則的例外是“DisallowSELECT*”，當(dāng)幾個(gè)處理需要一個(gè)表中行的不同的部分的時(shí)候。通過事務(wù)的整合,一次取回所有行,然后單獨(dú)處理這些部分。

　　技巧4:選擇唯一需要的行：

　　越少的行被檢索,查詢將運(yùn)行的越快。符合要求的行不得不令自己在存儲(chǔ)器中通過漫長(zhǎng)之旅,穿過緩沖池,階段1,階段2,可能的分類和轉(zhuǎn)換，然后傳遞結(jié)果集到調(diào)用程序。數(shù)據(jù)庫(kù)管理器管理所有的數(shù)據(jù)過濾；這對(duì)于檢索一行是非常浪費(fèi)的，測(cè)試在程序代碼里的那一行，然后過濾掉那行。禁止程序自動(dòng)過濾是一個(gè)必須強(qiáng)制執(zhí)行的鐵的規(guī)則。開發(fā)商可能選擇使用程序代碼執(zhí)行所有或部分的數(shù)據(jù)操作或者他們可能選擇使用SQL。典型地是混合在一起。已知的敘述顯示，過濾器可能被放入DB2engine里的程序代碼，類似:

　　　　IFTABLE-COL4>:VALUE
　　　　GETNEXTRESULTROW
?
　　技巧5:使用常量和字面值，如果值在以后的3年中不改變(對(duì)于靜態(tài)查詢)：

　　DB2優(yōu)化器對(duì)所有不均勻的分類統(tǒng)計(jì)都充分的使用,并為任何一個(gè)列統(tǒng)計(jì)提供了不同領(lǐng)域范圍內(nèi)的值，尤其當(dāng)沒有主機(jī)變量在謂詞中被發(fā)現(xiàn)時(shí),(WHERECOL5>'X')。主機(jī)變量的目的是使一個(gè)事務(wù)能適應(yīng)一個(gè)可變化的變量；當(dāng)一個(gè)用戶請(qǐng)求輸入這個(gè)值的時(shí)候是最經(jīng)常被使用的。主機(jī)變量不需要重新綁定一個(gè)程序，當(dāng)這個(gè)變量每一次改變的時(shí)候。這種可延伸性能得到優(yōu)化器準(zhǔn)確的耗費(fèi)。當(dāng)主機(jī)變量剛被發(fā)現(xiàn),(WHERECOL5>:hv5),優(yōu)化器使用以下的圖表來評(píng)估過濾器要素,而不是使用目錄統(tǒng)計(jì)。

　　列的基數(shù)性越高,則謂詞的過濾器要素就越低(保留部分行的預(yù)測(cè))。多數(shù)時(shí)候，這種評(píng)估有助于優(yōu)化器對(duì)適當(dāng)存取路徑的選取。然而,有時(shí)謂詞的過濾器要素遠(yuǎn)離實(shí)際。這就是通常需要對(duì)存取路徑進(jìn)行調(diào)優(yōu)的時(shí)候。

　　解決方案

　　QuestCentralforDB2是一個(gè)集成的控制臺(tái)，可以提供核心功能，DBA（數(shù)據(jù)庫(kù)管理員）需要執(zhí)行他們?nèi)粘５臄?shù)據(jù)庫(kù)管理任務(wù),空間管理,SQL調(diào)優(yōu)和分析,并且可以進(jìn)行性能診斷監(jiān)視。QuestCentralforDB2是由DB2軟件專家撰寫的，并且提供具豐富的功能，以利于視圖化的用戶界面，并且支持在Unix,Linux,和windows主機(jī)上運(yùn)行DB2數(shù)據(jù)庫(kù)。DB2的客戶不再被要求用獨(dú)立的工具維護(hù)和使用他們的主機(jī)和分布式的DB2系統(tǒng)。

　　QuestCentral的SQL調(diào)優(yōu)組件提供一個(gè)完整的SQL調(diào)優(yōu)環(huán)境。QuestCentral是唯一可以提供完整的SQL調(diào)優(yōu)環(huán)境的針對(duì)DB2可用的產(chǎn)品。這個(gè)環(huán)境包括以下部分：

　　1.調(diào)優(yōu)實(shí)驗(yàn)室：通過場(chǎng)景的使用，一個(gè)單獨(dú)的SQL語句能夠被改進(jìn)很多次。然后這些場(chǎng)景能夠立刻被比較以確定哪個(gè)SQL語句提供了最有效率的存取路徑。

　　2.比較：您立刻可以看出對(duì)于SQL語句修改的性能改變效果。由于比較多個(gè)場(chǎng)景,您能看到對(duì)CPU的效果,消耗的時(shí)間,I/O和其他更多的統(tǒng)計(jì)。另外數(shù)據(jù)的比較將保證您的SQL語句返回相同的數(shù)據(jù)子集。

　　3.建議：由SQL調(diào)優(yōu)組件提供的建議，將會(huì)發(fā)現(xiàn)所有的在白皮書指定的條件等等。另外,如果一個(gè)新場(chǎng)景可以利用，SQL調(diào)優(yōu)組件甚至將會(huì)重寫SQL，并綜合選擇的建議。

　　4.存取路徑和對(duì)應(yīng)的統(tǒng)計(jì)：在SQL的上下文中，對(duì)于DB2存取路徑，所有適合的統(tǒng)計(jì)應(yīng)被顯示出來。采取推測(cè)以設(shè)法理解為什么選擇一個(gè)特殊的存取計(jì)劃。

　　QuestCentralforDB2健壯的功能顯現(xiàn)了上述SQL調(diào)優(yōu)中的技巧以及更多。這篇白皮書剩余的部分將證明QuestCentral是由更豐富和更透徹的知識(shí)恰當(dāng)?shù)慕M成的。QuestCentral不僅可以提高您的SQL語句效率，更可以幫助您全面的提升數(shù)據(jù)庫(kù)的性能。上面描述的各種調(diào)優(yōu)技巧都被QuestCentral所包括。

　　解決的技巧1:核實(shí)特定提供的統(tǒng)計(jì):

　　一旦一條SQL語句在QuestCentral中被描述，建議欄會(huì)提供一整套建議，包括當(dāng)沒有RUNSTATS時(shí)也可以發(fā)現(xiàn)的能力。QuestCentral一直以堅(jiān)定的決心來探究這類建議。每一條建議都有相對(duì)應(yīng)的"建議操作"。這種建議操作會(huì)指導(dǎo)如何矯正建議發(fā)現(xiàn)的問題。這將會(huì)打開一個(gè)新的場(chǎng)景由被重寫的SQL或以促進(jìn)對(duì)象分析的腳本組成。在這個(gè)例子中,建議顯示,統(tǒng)計(jì)的缺失和相對(duì)應(yīng)的建議操作將建立一個(gè)腳本，它包含RUNSTATS命令，為了在建議操作的窗口中選擇任何一個(gè)對(duì)象。

　　并且能夠生成必要的命令對(duì)所有選擇對(duì)象的統(tǒng)計(jì)進(jìn)行更新。

　　另外,QuestCentralSpace的管理能夠自動(dòng)的收集、維護(hù)和檢驗(yàn)在表空間里的統(tǒng)計(jì)及表和索引等級(jí)。以下的例子顯示了在數(shù)據(jù)庫(kù)里所有表空間里的統(tǒng)計(jì)檢驗(yàn)報(bào)告。
　　
　　解決的技巧2:盡可能的提升階段2和階段1的謂詞:

　　SQL的調(diào)優(yōu)組件將列出所有的謂詞并指出那些謂詞是否是"Sargable"或"Non-Sargable"。另外,各個(gè)謂詞都將被檢查，以確定它是否具有索引存取的資袼。這種單獨(dú)的建議可以解決響應(yīng)時(shí)間的問題和在謂詞重寫的期間內(nèi)得到某些成果。在下面的例子中,一條查詢被看作non-sargable和non-indexable(階段2)。這條最初的查詢被輸入在一個(gè)謂詞間。一個(gè)新場(chǎng)景被打開了并且謂詞被重寫使用大于,小于符號(hào)。這種比較確定了查詢重寫對(duì)性能方面的影響。

　　一個(gè)新場(chǎng)景被創(chuàng)建并且查詢被重寫在列值中使用"a>="和"a<="。注意，謂詞現(xiàn)在是可索引的和sargable。記住以上的信息,謂詞現(xiàn)在將由數(shù)據(jù)管理器(階段1)處理，以減少這次查詢的潛在響應(yīng)時(shí)間。

　　隨后可以使用比較工具來比較他們和"<>"之間的性能,會(huì)發(fā)現(xiàn)"<>"更有效的減少消耗的時(shí)間。

　　解決的技巧3:選擇唯一需要的列:

　　SQL調(diào)優(yōu)的特點(diǎn)不僅是相對(duì)于使用"SELECT*"的建議,更提供一個(gè)事半功倍的可以令產(chǎn)品自動(dòng)重寫SQL的特點(diǎn)。建議和相對(duì)應(yīng)的建議操作將提供重寫您SQL的能力，簡(jiǎn)單地檢查想要的列并選擇"applyadvice"按鈕,SQL調(diào)優(yōu)將用被選擇的列替換"*"。

　　解決的技巧4：選擇唯一需要的行:

　　越少的行被檢索,查詢將運(yùn)行的越快。使用QuestCentral能比較您最初的SQL相對(duì)于選擇較少行但相同的SQL語句。使用多個(gè)場(chǎng)景和利用比較特點(diǎn),比較那些立刻顯示發(fā)生變化的性能影響的場(chǎng)景。在以下例子中，兩張表單的加入，產(chǎn)生了一個(gè)有意義的結(jié)果集。由于加入了"FetchFirst1RowOnly'"執(zhí)行時(shí)間顯著的減少了。

　　解決的技巧5:使用常量和字面值，如果值在以后的3年中不改變(對(duì)于靜態(tài)查詢):