oracle 資料庫訪問效能最佳化__Python

讀者對像：

開發人員：如果你是做資料庫開發，那本文的內容非常適合，因為本文是從程式員的角度來談資料庫效能最佳化。

架構師：如果你已經是資料庫應用的架構師，那本文的知識你應該清楚90%，否則你可能是一個喜歡折騰的架構師。

DBA（資料庫管理員）：大型資料庫最佳化的知識非常複雜，本文只是從程式員的角度來談效能最佳化，DBA除了需要瞭解這些知識外，還需要深入資料庫的內部體系架構來解決問題。

 

引言

在網上有很多文章介紹資料庫最佳化知識，但是大部份文章只是對某個一個方面進行說明，而對於我們程式員來說這種介紹並不能很好的掌握最佳化知識，因為很多介紹只是對一些特定的情境最佳化的，所以反而有時會產生誤導或讓程式員感覺不明白其中的奧妙而對資料庫最佳化感覺很神秘。

很多程式員總是問如何學習資料庫最佳化，有沒有好的教材之類的問題。在書店也看到了許多資料庫最佳化的專業書籍，但是感覺更多是面向DBA或者是PL/SQL開發方面的知識，個人感覺不太適合普通程式員。而要想做到資料庫最佳化的高手，不是花幾周，幾個月就能達到的，這並不是因為資料庫最佳化有多高深，而是因為要做好最佳化一方面需要有非常好的技術功底，對作業系統、儲存硬體網路、資料庫原理等方面有比較紮實的基礎知識，另一方面是需要花大量時間對特定的資料庫進行實踐測試與總結。

作為一個程式員，我們也許不清楚線上正式的伺服器硬體設定，我們不可能像DBA那樣專業的對資料庫進行各種實踐測試與總結，但我們都應該非常瞭解我們SQL的商務邏輯，我們清楚SQL中訪問表及欄位的資料情況，我們其實只關心我們的SQL是否能儘快返回結果。那程式員如何利用已知的知識進行資料庫最佳化。如何能快速定位SQL效能問題並找到正確的最佳化方向。

面對這些問題，筆者總結了一些面向程式員的基本最佳化法則，本文將結合執行個體來坦述資料庫開發的最佳化知識。 一、資料庫訪問最佳化法則簡介

要正確的最佳化SQL，我們需要快速定位能性的瓶頸點，也就是說快速找到我們SQL主要的開銷在哪裡。而大多數情況效能最慢的裝置會是瓶頸點，如下載時網路速度可能會是瓶頸點，本地複製檔案時硬碟可能會是瓶頸點，為什麼這些一般的工作我們能快速確認瓶頸點呢，因為我們對這些慢速裝置的效能資料有一些基本的認識，如網路頻寬是2Mbps，硬碟是每分鐘7200轉等等。因此，為了快速找到SQL的效能瓶頸點，我們也需要瞭解我們電腦系統的硬體基本效能指標，下圖展示的當前主StreamCompute機效能指標資料。

 

 

從圖上可以看到基本上每種裝置都有兩個指標：

延時（回應時間）：表示硬體的突發處理能力；

頻寬（輸送量）：代表硬體持續處理能力。

 

從上圖可以看出，電腦系統硬體效能從高到代依次為：

CPU——Cache(L1-L2-L3)——記憶體——SSD硬碟——網路——硬碟

由於SSD硬碟還處於快速發展階段，所以本文的內容不涉及SSD相關應用系統。

根據資料庫知識，我們可以列出每種硬體主要的工作內容：

CPU及記憶體：快取資料訪問、比較、排序、事務檢測、SQL解析、函數或邏輯運算；

網路：結果資料轉送、SQL請求、遠端資料庫訪問（dblink）；

硬碟：資料訪問、資料寫入、日誌記錄、大資料量排序、大表串連。

 

根據當前電腦硬體的基本效能指標及其在資料庫中主要操作內容，可以整理出如下圖所示的效能基本最佳化法則：

  

 

這個最佳化法則歸納為5個層次：

1、  減少資料訪問（減少磁碟訪問）

2、  返回更少資料（減少網路傳輸或磁碟訪問）

3、  減少互動次數（減少網路傳輸）

4、  減少伺服器CPU開銷（減少CPU及記憶體開銷）

5、  利用更多資源（增加資源）

 

由於每一層最佳化法則都是解決其對應硬體的效能問題，所以帶來的效能提升比例也不一樣。傳統資料庫系統設計是也是儘可能對低速裝置提供最佳化方法，因此針對低速裝置問題的可最佳化手段也更多，最佳化成本也更低。我們任何一個SQL的效能最佳化都應該按這個規則由上到下來診斷問題並提出解決方案，而不應該首先想到的是增加資源解決問題。

以下是每個最佳化法則層級對應最佳化效果及成本經驗參考：

 

 

最佳化法則	效能提升效果	最佳化成本
減少資料訪問	1~1000	低
返回更少資料	1~100	低
減少互動次數	1~20	低
減少伺服器CPU開銷	1~5	低
利用更多資源	@~10