qileilove

          blog已經(jīng)轉(zhuǎn)移至github,大家請(qǐng)?jiān)L問(wèn) http://qaseven.github.io/

          DB2數(shù)據(jù)庫(kù)應(yīng)用系統(tǒng)性能優(yōu)化深入探究

            DB2是一種高性能的大型關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng),廣泛的應(yīng)用在客戶/服務(wù)器體系結(jié)構(gòu)中。評(píng)價(jià)系統(tǒng)性能優(yōu)化的標(biāo)準(zhǔn)有:吞吐量、響應(yīng)時(shí)間、并行能力等。
            設(shè)計(jì)數(shù)據(jù)庫(kù)
            1、熟悉業(yè)務(wù)系統(tǒng)
            對(duì)業(yè)務(wù)系統(tǒng)的熟悉程度對(duì)整個(gè)數(shù)據(jù)庫(kù)系統(tǒng)的性能有很大影響,一個(gè)對(duì)業(yè)務(wù)不熟悉的設(shè)計(jì)人員,盡管有豐富的數(shù)據(jù)庫(kù)知識(shí),也很難設(shè)計(jì)出性能最佳的數(shù)據(jù)庫(kù)應(yīng)用系統(tǒng)。
            2、規(guī)范化與非規(guī)范化
            數(shù)據(jù)庫(kù)被規(guī)范化后,減少了數(shù)據(jù)冗余,數(shù)據(jù)量變小,數(shù)據(jù)行變窄。這樣DB2的每一頁(yè)可以包括更多行,那么每一區(qū)里的數(shù)據(jù)量更多,從而加速表的掃描,改進(jìn)了單個(gè)表的查詢性能。但是,當(dāng)查詢涉及多個(gè)表的時(shí)候,需要用很多連接操作把信息從各個(gè)表中組合在一起,導(dǎo)致更高的CPU和I/O花銷。那么,有很多時(shí)候需要在規(guī)范化和非規(guī)范化之間保持平衡,用適當(dāng)?shù)娜哂嘈畔?lái)減少系統(tǒng)開銷,用空間代價(jià)來(lái)?yè)Q取時(shí)間代價(jià)。有訂單信息表OrderDetail,它里面記錄了投遞員信息,收款員信息,物品信息,價(jià)格策略,客戶信息…..這些信息分別在投遞員信息表、收款員信息表、物品信息表、價(jià)格策略表、客戶信息表中存放。如果按照規(guī)范化的要求,OrderDetail查詢時(shí)就必須要與這么多個(gè)表進(jìn)行連接或者嵌套查詢。如果OrderDetail表中的數(shù)據(jù)量是在百萬(wàn)級(jí)的,那么一次查詢所需要的時(shí)間可能會(huì)達(dá)到好幾個(gè)小時(shí)。事實(shí)上,只要在設(shè)計(jì)時(shí)保證數(shù)據(jù)的邏輯有效性,很多信息都可以直接冗余在OrderDetail表中,這些冗余的數(shù)據(jù)能夠極大的提高查詢的效率,從而減少CPU和I/O操作。
            3、數(shù)據(jù)條帶化
            如果一個(gè)表的記錄條數(shù)超過(guò)一定的規(guī)模,那么最基本的查詢操作也會(huì)受到影響,需要將該表根據(jù)日期水平劃分,把最近、最經(jīng)常用的數(shù)據(jù)和歷史的、不經(jīng)常用的數(shù)據(jù)劃分開來(lái),或是根據(jù)地理位置、部門等等進(jìn)行劃分。還有一種劃分方式――垂直劃分,即把一個(gè)屬性列很多的表分割成好幾個(gè)小表,比如把經(jīng)常用到的屬性放在一個(gè)表里,不經(jīng)常用到的屬性放在另一個(gè)表里,這樣可以加快表的掃描,提高效率。
            4、選擇數(shù)據(jù)類型
            對(duì)每一屬性選擇什么樣的數(shù)據(jù)類型很大程度上依據(jù)表的要求,但是在不違背表要求的前提下,選擇適當(dāng)?shù)臄?shù)據(jù)類型可以提高系統(tǒng)性能。比如有text列存放一本書的信息,用BLOB而不是character(1024),BLOB存放的是指針或者文件參照變量,真正的文本信息可以放在數(shù)據(jù)庫(kù)之外,從而減少數(shù)據(jù)庫(kù)存儲(chǔ)空間,使得程序運(yùn)行的速度提高。DB2提供了UDT(User Defined Datatypes)功能,用戶可以根據(jù)自己的需要定義自己的數(shù)據(jù)類型。
            5、選擇索引
            索引是數(shù)據(jù)庫(kù)中重要的數(shù)據(jù)結(jié)構(gòu),它的根本目的就是為了提高查詢效率。現(xiàn)在大多數(shù)的數(shù)據(jù)庫(kù)產(chǎn)品都采用IBM最先提出的ISAM索引結(jié)構(gòu)。使用索引可以快速、直接、有序的存取數(shù)據(jù)。索引的建立雖然加快了查詢,另一方面卻將低了數(shù)據(jù)更新的速度,因?yàn)樾聰?shù)據(jù)不僅要增加到表中,也要增加到索引中。另外,索引還需要額外的磁盤空間和維護(hù)開銷。因此,要合理使用索引:
            在經(jīng)常進(jìn)行連接,但是沒有指定為外鍵的屬性列上建立索引。
            在頻繁進(jìn)行排序或分組(即進(jìn)行g(shù)roup by或order by操作)的列上建立索引。按索引來(lái)排序或分組,可以提高效率。
            在條件表達(dá)式中經(jīng)常用到的不同值較多的列上建立檢索,在不同值少的列上不要建立索引。
            如果待排序的列有多個(gè),可以在這些列上建立復(fù)合索引(compound index),即索引由多個(gè)字段復(fù)合而成。
            查詢優(yōu)化
            現(xiàn)在的數(shù)據(jù)庫(kù)產(chǎn)品在系統(tǒng)查詢優(yōu)化方面已經(jīng)做得越來(lái)越好,但由于用戶提交的SQL語(yǔ)句是系統(tǒng)優(yōu)化的基礎(chǔ),很難設(shè)想一個(gè)原本糟糕的查詢計(jì)劃經(jīng)過(guò)系統(tǒng)的優(yōu)化之后會(huì)變得高效,因此用戶所寫語(yǔ)句的優(yōu)劣至關(guān)重要。下面重點(diǎn)說(shuō)明改善用戶查詢計(jì)劃的解決方案。
            1、排序
            在很多時(shí)候,應(yīng)當(dāng)簡(jiǎn)化或避免對(duì)大型表進(jìn)行重復(fù)的排序。當(dāng)能夠利用索引自動(dòng)以適當(dāng)?shù)拇涡虍a(chǎn)生輸出時(shí),可以避免排序的步驟,當(dāng)以下的情況發(fā)生時(shí),排序就不能省略:
            索引中不包括一個(gè)或幾個(gè)待排序的列;
            group by或order by子句中列的次序與索引的次序不一樣;
            排序的列來(lái)自不同的表。
            為了避免不必要的排序,就要正確地增建索引,合理地合并數(shù)據(jù)庫(kù)表,盡管有時(shí)可能影響表的規(guī)范化,但相對(duì)于效率的提高是值得的。如果排序不可避免,那么應(yīng)當(dāng)試圖簡(jiǎn)化它,如縮小排序列的范圍等。

            2、主鍵
            主鍵用整型會(huì)極大的提高查詢效率,而字符型的比較開銷要比整型的比較開銷大很多,用字符型數(shù)據(jù)作主鍵會(huì)使數(shù)據(jù)插入、更新與查詢的效率降低。數(shù)據(jù)量小的時(shí)候這點(diǎn)降低可能不會(huì)被注意,可是當(dāng)數(shù)據(jù)量大的時(shí)候,小的改進(jìn)也能夠提高系統(tǒng)的響應(yīng)速度。
            3、嵌套查詢
            在SQL語(yǔ)言中,一個(gè)查詢塊可以作為另一個(gè)查詢塊中謂詞的一個(gè)操作數(shù)。因此,SQL查詢可以層層嵌套。例如在一個(gè)大型分布式數(shù)據(jù)庫(kù)系統(tǒng)中,有訂單表Order、訂單信息表OrderDetail,如果需要兩表關(guān)聯(lián)查詢:
          以下是代碼片段:
              SELECT CreateUser 
            FROM Order 
            WHERE OrderNo IN 
            ( SELECT OrderNo 
            FROM OrderDetail 
            WHERE Price=0.5)
            在這個(gè)查詢中,找出報(bào)紙單價(jià)為0.5元的收訂員名單。下層查詢返回一組值給上層查詢,然后由上層查詢塊再根據(jù)下層塊提供的值繼續(xù)查詢。在這種嵌套查詢中,對(duì)上層查詢的每一個(gè)值OrderNo,下層查詢都要對(duì)表OrderDetail進(jìn)行全部掃描,執(zhí)行效率顯然不會(huì)高。在該查詢中,有2層嵌套,如果每層都查詢1000行,那么這個(gè)查詢就要查詢100萬(wàn)行數(shù)據(jù)。在系統(tǒng)開銷中,對(duì)表Order的掃描占82%,對(duì)表OrderDetail的搜索占16%。如果我們用連接來(lái)代替,即:
          以下是代碼片段:
              SELECT CreateUser 
            FROM Order,OrderDetail 
            WHERE Order.OrderNo=OrderDetail.OrderNo AND Praice=0.5
            那么對(duì)表Order的掃描占74%,對(duì)表OrderDetail的搜索占14%。
            而且,一個(gè)列的標(biāo)簽同時(shí)在主查詢和where子句中的查詢中出現(xiàn),那么很可能當(dāng)主查詢中的列值改變之后,子查詢必須重新查詢一次。查詢嵌套層次越多,效率越低,因此應(yīng)當(dāng)盡量避免子查詢。如果子查詢不可避免,那么要在子查詢中過(guò)濾掉盡可能多的行。
            4、通配符
            在SQL語(yǔ)句中,LIKE關(guān)鍵字支持通配符匹配,但這種匹配特別耗費(fèi)時(shí)間。例如:SELECT * FROM Order WHERE CreateUser LIKE ‘M_ _ _’ 。即使在CreateUser字段上建立了索引,在這種情況下也還是采用順序掃描的方式,Order表中有1000條記錄,就需要比較1000次。如果把語(yǔ)句改為SELECT * FROM Order WHERE CreateUser >’M’ AND CreateUser <’N’,在執(zhí)行查詢時(shí)就會(huì)利用索引來(lái)查詢,顯然會(huì)大大提高速度。
            5、distinct
            使用distinct是為了保證在結(jié)果集中不出現(xiàn)重復(fù)值,但是distinct會(huì)產(chǎn)生一張工作表,并進(jìn)行排序來(lái)刪除重復(fù)記錄,這會(huì)大大增加查詢和I/O的操作次數(shù)。因此應(yīng)當(dāng)避免使用distinct關(guān)鍵字。
            6、負(fù)邏輯
            負(fù)邏輯如!=、<>、not in等,都會(huì)導(dǎo)致DB2用表掃描來(lái)完成查詢。當(dāng)表較大時(shí),會(huì)嚴(yán)重影響系統(tǒng)性能,可以用別的操作來(lái)代替。
            7、臨時(shí)表
            使用臨時(shí)表時(shí)數(shù)據(jù)庫(kù)會(huì)在磁盤中建立相應(yīng)的數(shù)據(jù)結(jié)構(gòu),因?yàn)閮?nèi)存的訪問(wèn)速度遠(yuǎn)遠(yuǎn)大于外部存儲(chǔ)器的訪問(wèn)速度,在復(fù)雜查詢中使用臨時(shí)表時(shí),中間結(jié)果會(huì)被導(dǎo)入到臨時(shí)表中,這種磁盤操作會(huì)大大降低查詢效率。另外,在分布式系統(tǒng)中,臨時(shí)表的使用還會(huì)帶來(lái)多個(gè)查詢進(jìn)程之間的同步問(wèn)題。所以,在進(jìn)行復(fù)雜查詢時(shí)最好不要使用臨時(shí)表。
            8、存儲(chǔ)過(guò)程
            DB2中的Stored Procedure Builder可以產(chǎn)生存儲(chǔ)過(guò)程,運(yùn)行并測(cè)試存儲(chǔ)過(guò)程。存儲(chǔ)過(guò)程可以包含巨大而復(fù)雜的查詢或SQL操作,經(jīng)過(guò)編譯后存儲(chǔ)在DB2數(shù)據(jù)庫(kù)中。用戶在多次使用同樣的SQL操作時(shí),可以先把這些SQL操作做成存儲(chǔ)過(guò)程,在需要用到的地方直接引用其名字進(jìn)行調(diào)用。存儲(chǔ)過(guò)程在第一次執(zhí)行時(shí)建立優(yōu)化的查詢方案,DB2將查詢方案保存在高速緩存里,以后調(diào)用運(yùn)行時(shí)可以直接從高速緩存執(zhí)行,省去了優(yōu)化和編譯的階段,節(jié)省了執(zhí)行時(shí)間,從而提高效率和系統(tǒng)利用率。
            最優(yōu)的查詢方案按照某些標(biāo)準(zhǔn)選擇往往不可行,要根據(jù)實(shí)際的要求和具體情況,通過(guò)比較進(jìn)行選擇。DB2提供的Query Patroller可以對(duì)不同的查詢方案的查詢代價(jià)進(jìn)行比較,通過(guò)追蹤查詢語(yǔ)句,返回查詢不同階段的系統(tǒng)開銷,從而作出最佳選擇。DB2提供的Performance Monitor也對(duì)整個(gè)數(shù)據(jù)庫(kù)系統(tǒng)的性能進(jìn)行監(jiān)控,包括I/O時(shí)間、查詢次數(shù)、排序時(shí)間、同步讀寫時(shí)間等等。
            數(shù)據(jù)庫(kù)系統(tǒng)的并發(fā)控制也能影響系統(tǒng)性能。多個(gè)用戶的同時(shí)操作可能導(dǎo)致數(shù)據(jù)的不一致性,DB2為了防止同時(shí)修改造成數(shù)據(jù)丟失和訪問(wèn)未被提交的數(shù)據(jù),以及數(shù)據(jù)的保護(hù)讀,采用Lock機(jī)制來(lái)實(shí)現(xiàn)控制。
            DB2中可以對(duì)表空間、表、表列和索引加鎖。鎖的粒度越大,鎖越簡(jiǎn)單,開銷小,并發(fā)度低;粒度小,鎖機(jī)制復(fù)雜,開銷大,并發(fā)度高。大型系統(tǒng)在并發(fā)處理中如果遇到所要分配的資源處于鎖定狀態(tài),系統(tǒng)會(huì)把進(jìn)程掛起等待。如果一個(gè)很耗時(shí)的查詢操作工作于一個(gè)經(jīng)常使用的表上,此時(shí)使用表一級(jí)鎖,意味著整個(gè)系統(tǒng)都要等待你的查詢結(jié)束以后才能夠繼續(xù)運(yùn)行。所以在復(fù)雜查詢中,盡量避免使用表一級(jí)鎖。如果有這一類的需要該怎么辦呢?可以利用視圖來(lái)解決這一類問(wèn)題。視圖避免了對(duì)表的直接操作,同時(shí)有能夠保證數(shù)據(jù)庫(kù)的高效運(yùn)轉(zhuǎn)。

          posted on 2011-12-05 09:34 順其自然EVO 閱讀(139) 評(píng)論(0)  編輯  收藏


          只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。


          網(wǎng)站導(dǎo)航:
           
          <2011年12月>
          27282930123
          45678910
          11121314151617
          18192021222324
          25262728293031
          1234567

          導(dǎo)航

          統(tǒng)計(jì)

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評(píng)論

          閱讀排行榜

          評(píng)論排行榜

          主站蜘蛛池模板: 加查县| 四川省| 务川| 龙海市| 邢台县| 波密县| 武宁县| 康定县| 杭锦后旗| 道孚县| 满洲里市| 永泰县| 华安县| 金华市| 江山市| 漾濞| 星座| 临高县| 新安县| 庐江县| 三河市| 盐源县| 尤溪县| 当雄县| 广昌县| 元朗区| 新野县| 新平| 宝丰县| 内江市| 正镶白旗| 济宁市| 织金县| 巴青县| 吉隆县| 扶风县| 太白县| 怀集县| 嘉鱼县| 甘泉县| 富源县|