資料庫訪問最佳化法則詳解之利用更多的資源

資料庫訪問最佳化法則詳解之利用更多的資源

利用更多的資源

可利用更多的資源，達到最佳化資料庫的目的。

用戶端的多進程並行訪問

多進程並行訪問是指在用戶端建立多個進程（線程），每個進程建立一個與資料庫的串連，然後同時向資料庫提交訪問請求。當資料庫主機資源有空閑時，我們可以採用用戶端多進程並行訪問的方法來提高效能。如果資料庫主機已經很忙時，採用多進程並行訪問，效能不會提高，反而可能會更慢。所以，最好與DBA 或系統管理員進行溝通後再決定是否採用這種方式。

例如：我們有10 000 個產品ID，現在需要根據ID 取出產品的詳細資料，如果單線程訪問，按每個IO 要5ms 計算，忽略主機的CPU 運算及網路傳輸時間，我們需要50s才能完成任務。如果採用5 個並行訪問，每個進程訪問2000 個ID，那麼10s 就有可能完成任務。

那是不是並行數越多越好呢？開1000 個並行，是否只要50ms 就能搞定？答案肯定是否定的。當並行數超過伺服器主機資源的上限時效能就不會再提高，如果再增加，反而會增加主機的進程間調度成本和進程衝突機率。

以下是一些如何設定並行數的基本建議：

（1）如果瓶頸在伺服器主機，但是主機還有空閑資源，那麼最大並行數取主機的CPU核心數和主機提供資料服務的磁碟數兩個參數中的最小值，同時要保證主機有資源做其他任務。

（2）如果瓶頸在用戶端處理上，但是用戶端還有空閑資源，那建議不要增加SQL 的並行，而是用一個進程取回資料後，在用戶端起多個進程處理即可，進程數根據用戶端的CPU 核心數計算。

（3）如果瓶頸在用戶端網路，那建議做資料壓縮或者增加多個用戶端，採用mapreduce 的架構處理。

（4）如果瓶頸在伺服器網路，那需要增加伺服器的網路頻寬或者在服務端將資料壓縮後再處理了。

資料庫的平行處理

資料庫的平行處理是指用戶端一條SQL 的請求，資料庫內部自動分解成多個進程平行處理，3-8 所示。

 

 

並不是所有的SQL 都可以使用平行處理，一般只有對錶或索引進行全部訪問時才可以使用並行。資料庫表預設是不開啟並行訪問的，所以需要指定SQL 並行的提示，如下所示：

select /*+parallel(a,4)*/ * from employee;

並行的優點：

使用多進程處理，充分利用資料庫主機資源（CPU 和IO），提高效能。

並行的缺點：

（1）單個會話佔用大量資源，影響其他會話，所以只適合在主機負載低的時期使用。

（2）只能採用直接IO 訪問，不能利用快取資料，所以執行前會觸發將髒快取資料寫入磁碟的操作。

註：（1）平行處理在OLTP 類系統中慎用。使用不當會導致一個會話把主機資源全部佔用，而正常事務得不到及時響應，所以其一般只是用於資料倉儲平台。

（2）一般而言，對於百萬級記錄以下的小表採用並行訪問的話，並不能提高，反而可能會更差。

寫在最後：效能最佳化是一門藝術，選擇了正確的方法可以讓你事半功倍。本文的最佳化法則帶給你的是正常思路，也可以說是基本知識。當然，也許有很多專家提出一些新的“奇門武功”，但往往不是常人可掌控，甚至會使人“走火入魔”，Oracle 資料庫中的一些配置參數最佳化就曾經讓許多人“走火入魔”。在這裡還需要強調一點，技術人最容易犯的錯誤是過度最佳化。

切記，效能最佳化是無止境的。當效能達到業務期望時，就不要再過度最佳化了，因為最佳化的成本會越來越高，過度最佳化會讓系統的可維護性及可擴充性降低。

 

 

本文選自《Oracle DBA手記3：資料庫效能最佳化與內部原理解析》一書

本書詳細資料:http://blog.csdn.net/broadview2006/article/details/6905948