db2資料庫性能

⑴ 【DB2】sql優化

於我來說，我喜歡技術，不偏執於某一類開發語言，願意花時間精力去解決問題。

1.去除在謂詞列上編寫的任何標量函數

優化前：(耗時3.1s)

優化後：(耗時0.922s)

總結：

DB2可以選擇使用START_DATE上的列索引，但是在列上使用了函數後，DB2就無法使用列索引了，從而導致查詢效率變低。

2.去除在謂詞列上編寫的任何數學運算

優化前：(耗時10.265)

優化後：(耗時3.39s)

總結：

DB2查詢時候，會優先選擇列CONTRACT_AMT上的索引，如果直接對列CONTRACT_AMT應用數學運算，DB2就無法使用索引了。一定要做到：列本身(不加數學運算)放在操作符的一邊，而所有的計算都放在另外一邊。

3.SQL語句中指定查詢列

優化前：(耗時13.15s)

優化後：(耗時2.922s)

總結：

如果Select包含不需要的列，優化工具會選擇Indexonly=』N』,這會強制DB2必須進入數據頁來得到所請求的特定列，這就要求更多的I/O操作，梁歪，這些多餘的列可能是某些排序的部分，這樣一來就需要和傳遞一個更大的排序文件，相應的會使排序成本更高。

4.盡可能不使用distinct

優化前：(耗時0.687s)

優化後：(耗時0.437s)

總結：

在測試distinct與group by性能的過程中，在列CST_ID上添加索引後，發現group by 確實比distinct快一些，但是在數據分布比較離散的情況下使用group by ，比較集中的情況下使用distinct.表數據量較少的情況隨便使用哪個都一樣， 不管選擇誰，都要建立索引

5.Exists、in、not in 、not exists的使用場景選擇

5.1 in跟exists的區別：

例如：表A(小表)，表B(大表)

優化前：(耗時1.93s)

優化後：(耗時1.125s)

相反的，

優化前：(耗時1.9s)

優化後：(耗時1.0s)

總結：

in是把外表和內表作hash連接，而exists是對外表作loop循環，每次loop循環再對內表進行查詢，一直以來認為exists比in效率高的說法是不準確的。 如果查詢的兩個表大小相當，那麼用in和exists差別不大；如果兩個表中一個較小一個較大，則子查詢表大的用exists，子查詢表小的用in；

簡稱：子大Exists,子小in

5.2 not in 與 not exists區別：

如果查詢語句使用了not in，那麼對內外表都進行全表掃描，沒有用到索引；而not exists的子查詢依然能用到表上的索引。所以無論哪個表大，用not exists都比not in 要快。

6.盡可能使用union all來代替union

優化前：(耗時15.344s)

優化後：(耗時2.719s)

總結：

在union中，DB2最後會自動執行一個排序來消除重復值，這樣是很耗費資源的，所以在不需要去重復的情況下，盡可能使用UNION ALL 代替union

N.模板

優化前：(耗時3.1s)

優化後：(耗時0.922s)

總結：

⑵ 在資料庫設計過程中要注意哪些問題

DB2資料庫的性能與穩定性直接跟資料庫對象的多少、大小有關。如果對象很少，不復雜，那麼就算不怎麼規劃，也能夠達到比較高的性能。如果對象數據比較多、比較大的話，那麼就需要在資料庫設計之前好好的規劃，否則會在很大程度上影響資料庫的性能與穩定性。

一、選擇合適的語言與資料庫字元集。

在企業中部署資料庫的時候，首先需要在操作系統上安裝資料庫。而在安裝資料庫的時候，需要選擇安裝的語言環境。即是以中文狀態下安裝資料庫還是以英文狀態安裝資料庫。如在啟動安裝程序的時，可以利用/i language選項來指定安裝過程中所採用的語言。到目前為止，DB2資料庫已經支持很多種語言。那麼資料庫在安裝過程中，該採用什麼語言呢？筆者建議，只要資料庫管理員有一點英語基礎，最好能夠採用英文語言環境來進行安裝。雖然說現在DB2資料庫的中文語言環境已經設計的比較完善，但是筆者仍然擔心其有一些不知名的漏洞。為此筆者在安裝DB2資料庫的時候，基本上都採用的是英文語言環境來進行安裝。即將語言設置為「EN」，表示英文。提高DB2數據備份與恢復的效率。

另外如果DB2 資料庫中要保存英文以外的數據，或者說用戶會使用不同的字元集訪問資料庫時，還需要在資料庫安裝過程中選擇特定的資料庫字元集。DB2資料庫中的所有字元數據，包括數據字典中的數據，都是存儲在資料庫字元集中的。如果用戶使用不同的字元集訪問資料庫時，資料庫管理員就需要選擇包含所有這些用戶的字元集的超集。只有如此，才能夠確保系統能夠很方便的使用替代字元完成字元的轉換，從而提高資料庫的性能。如果用戶選擇的字元集不對，有可能會出現一些莫名其妙的問題。如一次用戶在安裝資料庫過程中，沒有選擇合適的字元集。雖然在使用的過程中，其存儲中文字元沒有問題。但是當對資料庫採取還原操作時，卻發現還原後的資料庫中有些原來是中文字元的地方，盡然出現了亂碼。這主要就是沒有選擇合適的字元集惹的禍。有時候如果字元集選擇不當的話，從外部數據源(如Excel表格)導入數據的時候，中文數據也會無法順利導入。所以，資料庫管理員在安裝資料庫的時候，需要根據實際企業，來選擇合適的字元集。

二、評估資料庫對象的大小、數量。

DB2資料庫的性能與穩定性直接跟資料庫對象的多少、大小有關。如果對象很少，不復雜，那麼就算不怎麼規劃，也能夠達到比較高的性能。如果對象數據比較多、比較大的話，那麼就需要在資料庫設計之前好好的規劃，否則會在很大程度上影響資料庫的性能與穩定性。其實DB2 資料庫就好像一個倉庫，資料庫中的對象(如索引、數據表、表空間)等等就好像倉庫中的貨物。如果貨物比較少，那麼隨便放放，倉庫都顯得很空曠。貨物尋找起來也會很方便。但是如果貨物數量比較多、比較大，就必須要對其存儲空間進行合理規劃。只有如此才能夠讓倉庫的空間利用率達到最佳狀態。並且貨物的存放有序，在查找起來也特別的方便。筆者這里就以倉庫管理為例，說話該如何做好資料庫對象大小、數量等方便的評估，以及他們對於資料庫性能與穩定性的影響。

1、根據對象大小來規劃存儲空間。在倉庫貨物的擺放上，要根據貨物的大小來規劃存儲空間。或者說要首先防止大的貨物。只有如此空間的利用率才會最高。其實在規劃DB2對象的時候，也是如此。如某些表可能會包含的記錄比較多，屬於大表。此時資料庫管理員就需要考慮，是否將其放置在一個獨立的表空間或者硬碟空間上，以提高數據操作的性能。大表所對應的索引往往也是比較大的。為此在硬體條件允許的情況下，將索引表與數據表分別存放在不同的硬碟上，可以提高資料庫的性能。而對於一些比較小的對象(如數據表)，可以將它們存放在一個表空間中。其實這個表空間就好像倉庫中的一個個紙盒子。將小的對象放入到這個「紙盒子」中，不但不佔空間，而且也容易管理。

2、根據對象的使用頻率來規劃存放空間。在倉庫中擺放物品的時候，往往會把近期就要用到的貨物或者頻繁需要用到的東西放在倉庫門口或者容易拿到的地方。如此在拿這些貨物時就會比較便捷，也不會對其他貨物產生影響。對於DB2資料庫中的對象來說，也是這么一回事。可以將那些訪問量比較大的對象，如索引、數據表，存放在性能比較好的硬碟上或者單獨的硬碟中。此時訪問這些數據，就不會與其它對象產生I/O沖突，操作起來速度就會比較快。而將不怎麼用到的對象，存放在一起。由於他們不怎麼被用到，所以即使存放在性能比較低的硬碟上，其對資料庫性能產生的負面影響也是非常有限的。 在DB2資料庫裡面如何更新執行計劃

3、根據類別來存放資料庫對象。在倉庫中存放貨物的時候，還會對其進行分類。然後根據類別來進行存放。這有利於貨物的管理與檢索。其實在資料庫對象存儲空間設計時，也需要考慮這個因素。如現在應用軟體在設計的時候，很多都是根據模塊來設計。那麼在資料庫對象設計時，也需要根據這個模塊來設計存儲的空間。如將同一個模塊的資料庫對象存放在同一個表空間內。不過這可能會跟上面的兩個建立相違背。此時最好是在對象的命名上做文章。如可以根據模塊的不同，分別給資料庫對象取一個相同的前綴或者後綴。如即使同一塊模塊要用到多個表空間，此時就可以給表空間一個相同的前綴。如此在管理資料庫對象的時候，根據表空間的前綴就可以判斷其所屬的模塊了。如果再加上一個後綴來表示其資料庫對象的分類，那麼就更合理了。為此在管理資料庫對象的時候，要執行分類管理。不僅要從技術上對其進行分類，如分為索引、數據表、關鍵字等等。還需要從功能上進行分類，如按應用程序的模塊來進行分類等等。

三、設計好資料庫備份與還原的方案。

在資料庫交付生產使用之後，往往需要進行大量的測試。但是在測試過程中往往又會產生很多的垃圾數據。可是交給企業應用的，肯定是一個干凈的資料庫系統。為此在資料庫設計的時候，就需要想好如果減少測試過程中的垃圾數據。或者採取什麼樣的方式來實現在交互時自動清除垃圾數據的機制。

一般來說，想要一個資料庫備份與還原的方案，減少資料庫測試所產生的垃圾數據。如現在在給企業部署資料庫的時候，往往是先安裝一個干凈的資料庫系統。當然字元集這些需要預先設置好。然後再利用資料庫還原功能將預先定義好的資料庫模型還原出來。

另外有些時候需要兩個方案互為補充。如在資料庫初始化的過程中，採用資料庫還原的方式來創建資料庫對象。但是在應用軟體升級的時候，由於此時已經有了用戶的數據，為此不能夠在使用資料庫還原的方法。而是通過應用程序來執行某些SQL代碼，來調整或者增加部分資料庫對象。無論採用哪一種方式，需要遵循的一個原則就是在給企業創建資料庫對象時要最大限度的減少測試。而要做到這一點，就是需要先在測試伺服器上創建對象並測試對象可用。然後直接將相關的SQL代碼在投入使用的資料庫伺服器上執行。

⑶ sqlserver和DB2的區別

主要區別在於資料庫性能
SQL Server 屬於中型資料庫，主要應用於一般商用環境，處理百萬到千萬級數據量是沒有問題的，而DB2屬於大型資料庫，主要用於電信級或者數據中心級應用，可處理億級以上數據量。
另外SQL Server 只能運行在Windows 環境下，而DB2主要運行在UNIX或Linux環境下，因此 DB2性能總體優於SQL Server。

⑷ 怎麼用loadrunner 壓測 DB2資料庫伺服器性能

這個需要寫代碼
大致是：首先定義資料庫的用戶名、密碼、資料庫名
然後連接JDBC資料庫，寫個if語句判斷
測試你的SQL語句
最後清理緩存

⑸ DB2與SQL Server的區別

一、適用平台上的差異。
到目前為止，微軟的SQL Server數據據庫只支持微軟的操作系統。而DB2 資料庫不僅支持Windows操作系統，而且還支持Linux等開源操作系統。也就是說，DB2具有很好的跨平台性能。現在很多企業中，都是以Linux或者Unix操作系統作為資料庫伺服器的。這主要是因為從安全性和穩定性上面Linux或者Unix操作系統都要比Windows操作系統略勝一籌。所以從這一點來說，DB2 資料庫就要比SQLServer資料庫的應用面要廣。
二、安全性上的差異。
對於資料庫來說，特別是那些相互聯網用戶開發的資料庫系統，安全性一直是左右資料庫選型的主要因素。而在這個安全性上面，SQLServer資料庫與DB2資料庫之間有很大的差異。據筆者所知，SQLServer資料庫到目前為止，沒有取得任何國際上認可的安全證書。而對於DB2資料庫來說，其已經獲得了國際上最高級別的ISO標准認證。，雖然說證書不能夠說明問題，但是至少說明DB2 資料庫的安全性也是有所保障的。微軟在SQLServer資料庫上安全投入的不足，讓其無法適應互聯網安全的威脅。為此這也讓SQLServer資料庫少了很多訂單。
三、數據處理上的差異。
在數據處理的能力上，SQLServer資料庫與DB2資料庫也有很大的差異。SQLServer資料庫雖然支持多用戶，但是在大量並發訪問的情況下，性能會顯著下降。而DB2 資料庫可以說是專門為處理大量的並發訪問所涉及的。在數據處理上，如果並發行訪問比較少或者數據量並不是很大，那麼DB2資料庫與SQLServer資料庫相比，並不會有很大的優勢。甚至可能還是SQLServer資料庫的性能比較好。但是如果涉及到海量數據的處理，如數據倉庫或者企業級的應用，那麼DB2資料庫的性能就要遠遠超過SQLServer資料庫。從這一點上來說，DB2 資料庫適合一些企業級的應用，而SQLServer資料庫則因為價格相對便宜、維護相對簡單，而比較適合中小企業使用。
四、在投資成本上的差異。
企業部署資料庫應用時，所耗費的成本主要有三塊，分別為硬體上的投資、資料庫授權與人員的支出。在硬體上的投資，兩個資料庫沒有多大的差異。但是在資料庫的授權成本與人員的支出上，卻有很大的差異。從資料庫的授權成本上看，DB2 資料庫要比SQLServer資料庫高的多。從人員的支出看，企業招募一個DB2 資料庫管理員要比招募一個SQLServer資料庫管理員貴的多。這主要是因為DB2資料庫管理員比較少，而且其往往需要同時維護多個分支機構的應用。所以DB2資料庫管理員的價格就要比SQLServer的價格貴好幾倍。所以說，從整體成本來看，企業部署DB2資料庫要比採用SQLServer資料庫貴許多。
可見DB2與SQLServer資料庫各有優劣。企業需要根據自己的規模、對於安全性的考慮、性能上的要求以及可以接受的成本等多方面來進行權衡，才能夠選擇一個合適自己的資料庫系統。

⑹ 資料庫在金融行業中的應用

DB2資料庫為何在金融領域應用如此廣泛？在我接觸過的銀行用戶中，絕大部分都在使用IBM DB2資料庫產品，當然還是有一大批證劵公司也在使用。給我印象最為深刻的一次是在深圳辦的一場DB2技術專家沙龍，那次來的基本上都銀行用戶和證劵用戶。當時，就在想，DB2資料庫產品在金融領域應用咋那麼廣呢？

在開始這個討論之前，我也問了一些朋友，問他們是什麼原因導致了這一事實的發生，其中有人回答是歷史原因，也有人回答是因為DB2資料庫產品好。當然，眾多金融客戶選擇DB2資料庫產品，肯定是有各自的原因，歷史原因也罷，功能強大、性能穩定也罷，肯定各有說詞。不過我們可以想像一下，對於金融用戶來說，每天所產生的數據都非常多，且復雜，而且這些數據都相當重要，來不到半點馬虎。因此，他們在選擇資料庫產品的時候，自然是分外小心，不敢怠慢。另外，作為一家金融企業，在IT上的預算肯定也比較充足，所以產品的價格自然不是他們擔心的問題（當然，這只是一種猜測！）。這樣再分析原因的時候，我們就把重點放在了DB2資料庫的性能和穩定性上。那麼，究竟是不是了DB2資料庫的性能和穩定性導致了它在金融領域的應用如此廣泛呢，我不得而知！

針對這個『DB2資料庫為何在金融領域應用如此廣泛？』的疑問，是一個值得我們思索的過程。但至於是什麼真正的原因導致的，我這主題中就不詳細聊了，因為我的答案都是來源於大家，只有有了大家的支持，這個答案才會日漸豐富，日漸完善。

DB2的並發性、穩定性、擴展性這些都做得不錯，
金融行業很多業務是實時性交易很強的系統它們追求的是系統的穩定性，性能好，支持高並發、安全性高
所以選擇ORACLE、DB2這類資料庫等等
主要是用DB2 在用AIX系統 本身兼容性又好吧這樣穩定性更強，而且DB2 剛開始打開市場時是免費使用的

在金融行業，大家知道數據量大，數據復雜，更新頻繁，把大量而且關系復雜的數據進行整合，二次加工，做個決策分析，這些工作的前提都是要有一個穩定高效的資料庫。IBM DB2具有很好的安全性，數據可移植性，其他資料庫數據可以移植過來，又善於處理關系復雜的數據，而且速度快，連接方式靈活，可通過 ODBC、JBDC、網路服務、本地客戶機或非同步客戶機介面來實現，總之，相對其他資料庫DB2具有明顯的優勢，正好符合銀行的要求。

金融行業使用 DB2 可能是有其歷史原因的， 因為金融行業本身用 IBM 的主機就比較多 ：）
還是聽金融行業的兄弟們站出來說句吧

大家好
在金融行業中，我想大部分的業務系統使用的是DB2，而絕大部分的經營分析系統用的是teradata，我所知道就有工行，建行，中行，光大，浦發，民生，郵政銀行等等，IBM的產品一貫是安全性的代表，在銀行交易數據極其重要的前提下，選擇DB2是一個不錯的選擇，同時，DB2的大數據處理速度也僅次於teradata，另外很多銀行的硬體選擇了IBM的大機，自然iBM的軟體產品也是他們考慮的重中之重，至於teradata，在成功實施了walmart，ebay等超大的數據倉庫後，在入主中國也強勢地拿下了近10省的移動的經分系統和移動集團公司的經分系統，同時又很成功的實施了上海證交所的DW，這些事實的確證明了他們是數據倉庫行業的領導者，如果不缺錢，我相信選擇teradata做構建EDW是一個不錯的選擇！

我認為主要有以下幾點：
1、歷史原因
金融行業對於數據安全和系統可用性要求很高，因此，選用IBM主機的頗多。而DB2最初就是建立在主機操作系統上的，毫無疑問，是與IBM主機配合最好的資料庫產品，所以自然就會選擇DB2資料庫。由於對DB2比較熟悉，在開放式系統上也就選擇了DB2資料庫。
2、IBM技術支持和售後服務做的很好，產品性價比較高
根據我個人的親身體驗，IBM能夠根據客戶的需求進行電話或者現場技術支持，能夠根據客戶要求參與項目建設，與ORACLE相比，售後服務價格相對較低。
3、產品自身為用戶提供了較多的監控和分析工具，便於用戶自己進行問題診斷和性能優化

⑺ ibm db2 是世上最強資料庫嗎

DB2和oracle以及MS的SQL Server比的話，某種意義上說，確實是更強的。
Oralce現在比較流行，大中型資料庫一般都會使用Oracle，操作確實比DB2更方便，DB2主要是更遵守SQL本身的規則（因為SQL本身就是IBM提出的），並沒有像Oracle一樣擴展出自己的PL/SQL。所以用起來沒那麼方便，很多東西需要自己去實現。
但是DB2擁有最好的查詢優化器(資料庫的核心)，也就意味著它能更高效的處理海量數據。這是其他所有資料庫都比不了的。另外還有不少重要特性都比Oracle強一些（比如磁碟負載自動平衡、XML處理能力等）。再配上IBM為DB2量身定製的大型機、小型機，DB2處理海量資料庫的性能是其他資料庫比不了的，因此各大銀行，證券交易所等更多地使用DB2。一般的大中型資料庫則用得少，畢竟貴一些，難一些，DB2的必要性淡一些。
很多資料庫技術都是IBM首創的，可以說，DB2在技術方面一直是業界領軍的。
SQL Server、MySQL之類就不說了，它們主要應用於中小型資料庫。跟DB2和Oracle還是有差距的。
不過說世上最強不大合適，畢竟有些資料庫在一些特定領域能夠有更好的表現。

⑻ 基於DB2的資料庫應用系統的性能優化

摘要 結合DB 的使用經驗 從資料庫設計 查詢優化 並發控制 客戶/伺服器模式四個方面來討論資料庫應用系統性能優化的一些原則 方法等

關鍵詞 DB 性能優化 資料庫設計 查詢優化 並發控制 C/S模式

引言

DB 是一種高性能的大型關系資料庫管理系統 廣泛的應用在客戶/伺服器體系結構中 評價系統性能優化的標准有 吞吐量 響應時間 並行能力等 本文從資料庫的設計 查詢的優化 並發控制以及客戶/伺服器模式這四個角度來討論優化系統性能

設計資料庫

熟悉業務系統

對業務系統的熟悉程度對整個資料庫系統的性能有很大影響 一個對業務不熟悉的設計人員 盡管有豐富的資料庫知識 也很難設計出性能最佳的資料庫應用系統

規范化與非規范化

資料庫被規范化後 減少了數據冗餘 數據量變小 數據行變窄 這樣DB 的每一頁可以包括更多行 那麼每一區里的數據量更多 從而加速表的掃描 改進了單個表的查詢性能 但是 當查詢涉及多個表的時候 需要用很多連接操作把信息從各個表中組合在一起 導致更高的CPU和I/O花銷 那麼 有很多時候需要在規范化和非規范化之間保持平衡 用適當的冗餘信息來減少系統開銷 用空間代價來換取時間代價 有訂單信息表OrderDetail 它裡面記錄了投遞員信息 收款員信息 物品信息 價格策略 客戶信息… 這些信息分別在投遞員信息表 收款員信息表 物品信息表 價格策略表 客戶信息表中存放 如果按照規范化的要求 OrderDetail查詢時就必須要與這么多個表進行連接或者嵌套查詢 如果OrderDetail表中的數據量是在百萬級的 那麼一次查詢所需要的時間可能會達到好幾個小時 事實上 只要在設計時保證數據的邏輯有效性 很多信息都可以直接冗餘在OrderDetail表中 這些冗餘的數據能夠極大的提高查詢的效率 從而減少CPU和I/O操作

數據條帶化

如果一個表的記錄條數超過一定的規模 那麼最基本的查詢操作也會受到影響 需要將該表根據日期水平劃分 把最近 最經常用的數據和歷史的 不經常用的數據劃分開來 或是根據地理位置 部門等等進行劃分 還有一種劃分方式――垂直劃分 即把一個屬性列很多的表分割成好幾個小表 比如把經常用到的屬性放在一個表裡 不經常用到的屬性放在另一個表裡 這樣可以加快表的掃描 提高效率

選擇數據類型

對每一屬性選擇什麼樣的數據類型很大程度上依據表的要求 但是在不違背表要求的前提下 選擇適當的數據類型可以提高系統性能 比如有text列存放一本書的信息 用BLOB而不是character( ) BLOB存放的是指針或者文件參照變數 真正的文本信息可以放在資料庫之外 從而減少資料庫存儲空間 使得程序運行的速度提高 DB 提供了UDT（User Defined Datatypes）功能 用戶可以根據自己的需要定義自己的數據類型

選擇索引

索引是資料庫中重要的數據結構 它的根本目的就是為了提高查詢效率 現在大多數的資料庫產品都採用IBM最先提出的ISAM索引結構 使用索引可以快速 直接 有序的存取數據 索引的建立雖然加快了查詢 另一方面卻將低了數據更新的速度 因為新數據不僅要增加到表中 也要增加到索引中 另外 索引還需要額外的磁碟空間和維護開銷 因此 要合理使用索引

●在經常進行連接 但是沒有指定為外鍵的屬性列上建立索引

●在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引 按索引來排序或分組 可以提高效率

●在條件表達式中經常用到的不同值較多的列上建立檢索 在不同值少的列上不要建立索引

●如果待排序的列有多個 可以在這些列上建立復合索引（pound index） 即索引由多個欄位復合而成

查詢優化

現在的資料庫產品在系統查詢優化方面已經做得越來越好 但由於用戶提交的SQL語句是系統優化的基礎 很難設想一個原本糟糕的查詢計劃經過系統的優化之後會變得高效 因此用戶所寫語句的優劣至關重要 下面重點說明改善用戶查詢計劃的解決方案

． 排序

在很多時候 應當簡化或避免對大型表進行重復的排序 當能夠利用索引自動以適當的次序產生輸出時 可以避免排序的步驟 當以下的情況發生時 排序就不能省略

●索引中不包括一個或幾個待排序的列

●group by或order by子句中列的次序與索引的次序不一樣

●排序的列來自不同的表

為了避免不必要的排序 就要正確地增建索引 合理地合並資料庫表 盡管有時可能影響表的規范化 但相對於效率的提高是值得的 如果排序不可避免 那麼應當試圖簡化它 如縮小排序列的范圍等

． 主鍵

主鍵用整型會極大的提高查詢效率 而字元型的比較開銷要比整型的比較開銷大很多 用字元型數據作主鍵會使數據插入 更新與查詢的效率降低 數據量小的時候這點降低可能不會被注意 可是當數據量大的時候 小的改進也能夠提高系統的響應速度

． 嵌套查詢

在SQL語言中 一個查詢塊可以作為另一個查詢塊中謂詞的一個操作數 因此 SQL查詢可以層層嵌套 例如在一個大型分布式資料庫系統中 有訂單表Order 訂單信息表OrderDetail 如果需要兩表關聯查詢

SELECT CreateUserFROM Order WHERE OrderNo IN(SELECT OrderNoFROM OrderDetail WHERE Price= )

在這個查詢中 找出報紙單價為 元的收訂員名單 下層查詢返回一組值給上層查詢 然後由上層查詢塊再根據下層塊提供的值繼續查詢 在這種嵌套查詢中 對上層查詢的每一個值OrderNo 下層查詢都要對表OrderDetail進行全部掃描 執行效率顯然不會高 在該查詢中 有 層嵌套 如果每層都查詢 行 那麼這個查詢就要查詢 萬行數據 在系統開銷中 對表Order的掃描占 ％ 對表OrderDetail的搜索占 ％ 如果我們用連接來代替 即

SELECT CreateUserFROM Order OrderDetailWHERE Order OrderNo=OrderDetail OrderNo AND Praice=

那麼對表Order的掃描占 ％ 對表OrderDetail的搜索占 ％

而且 一個列的標簽同時在主查詢和where子句中的查詢中出現 那麼很可能當主查詢中的列值改變之後 子查詢必須重新查詢一次 查詢嵌套層次越多 效率越低 因此應當盡量避免子查詢 如果子查詢不可避免 那麼要在子查詢中過濾掉盡可能多的行

． 通配符

在SQL語句中 LIKE關鍵字支持通配符匹配 但這種匹配特別耗費時間 例如 SELECT * FROM Order WHERE CreateUser LIKE M_ _ _ 即使在CreateUser欄位上建立了索引 在這種情況下也還是採用順序掃描的方式 Order表中有 條記錄 就需要比較 次 如果把語句改為SELECT * FROM Order WHERE CreateUser > M AND CreateUser < N 在執行查詢時就會利用索引來查詢 顯然會大大提高速度

． distinct

使用distinct是為了保證在結果集中不出現重復值 但是distinct會產生一張工作表 並進行排序來刪除重復記錄 這會大大增加查詢和I/O的操作次數 因此應當避免使用distinct關鍵字

． 負邏輯

負邏輯如!= <> not in等 都會導致DB 用表掃描來完成查詢 當表較大時 會嚴重影響系統性能 可以用別的操作來代替

． 臨時表

使用臨時表時資料庫會在磁碟中建立相應的數據結構 因為內存的訪問速度遠遠大於外部存儲器的訪問速度 在復雜查詢中使用臨時表時 中間結果會被導入到臨時表中 這種磁碟操作會大大降低查詢效率 另外 在分布式系統中 臨時表的使用還會帶來多個查詢進程之間的同步問題 所以 在進行復雜查詢時最好不要使用臨時表

． 存儲過程

DB 中的Stored Procere Builder可以產生存儲過程 運行並測試存儲過程 存儲過程可以包含巨大而復雜的查詢或SQL操作 經過編譯後存儲在DB 資料庫中 用戶在多次使用同樣的SQL操作時 可以先把這些SQL操作做成存儲過程 在需要用到的地方直接引用其名字進行調用 存儲過程在第一次執行時建立優化的查詢方案 DB 將查詢方案保存在高速緩存里 以後調用運行時可以直接從高速緩存執行 省去了優化和編譯的階段 節省了執行時間 從而提高效率和系統利用率

最優的查詢方案按照某些標准選擇往往不可行 要根據實際的要求和具體情況 通過比較進行選擇 DB 提供的Query Patroller可以對不同的查詢方案的查詢代價進行比較 通過追蹤查詢語句 返回查詢不同階段的系統開銷 從而作出最佳選擇 DB 提供的Performance Monitor也對整個資料庫系統的性能進行監控 包括I/O時間 查詢次數 排序時間 同步讀寫時間等等

資料庫系統的並發控制也能影響系統性能 多個用戶的同時操作可能導致數據的不一致性 DB 為了防止同時修改造成數據丟失和訪問未被提交的數據 以及數據的保護讀 採用Lock機制來實現控制

lishixin/Article/program/DB2/201311/21921

⑼ DB2和Oracle的區別

Oracle和DB2是兩種不同的資料庫。
Oracle：
Oracle是甲骨文公司的一款關系資料庫管理系統。
ORACLE資料庫系統是美國ORACLE公司（甲骨文）提供的以分布式資料庫為核心的一組軟體產品，是目前最流行的客戶/伺服器(CLIENT/SERVER)或B/S體系結構的資料庫之一。比如SilverStream就是基於資料庫的一種中間件。ORACLE資料庫是目前世界上使用最為廣泛的資料庫管理系統，作為一個通用的資料庫系統，它具有完整的數據管理功能；作為一個關系資料庫，它是一個完備關系的產品；作為分布式資料庫它實現了分布式處理功能。
DB2：
全稱為IBM DB2。是美國IBM公司開發的一套關系型資料庫管理系統，它主要的運行環境為UNIX（包括IBM自家的AIX）、Linux、IBM i（舊稱OS/400）、z/OS，以及Windows伺服器版本。
DB2主要應用於大型應用系統，具有較好的可伸縮性，可支持從大型機到單用戶環境，應用於所有常見的伺服器操作系統平台下。 DB2提供了高層次的數據利用性、完整性、安全性、可恢復性，以及小規模到大規模應用程序的執行能力，具有與平台無關的基本功能和SQL命令。DB2採用了數據分級技術，能夠使大型機數據很方便地下載到LAN資料庫伺服器，使得客戶機/伺服器用戶和基於LAN的應用程序可以訪問大型機數據，並使資料庫本地化及遠程連接透明化。 DB2以擁有一個非常完備的查詢優化器而著稱，其外部連接改善了查詢性能，並支持多任務並行查詢。 DB2具有很好的網路支持能力，每個子系統可以連接十幾萬個分布式用戶，可同時激活上千個活動線程，對大型分布式應用系統尤為適用。

⑽ 資料庫DB2中什麼是性能問題

資料庫系統主要管理資料庫的存儲、事務以及對資料庫的操作。 文件系統是操作系統管理文件和存儲空間的子系統，主要是分配文件所佔的簇、盤塊或者建立FAT、管理空間空間等。 一般來說資料庫系統會調用文件系統來管理自己的數據文件