在過往與很多人的交流過程中發現，在談到基於硬體來進行資料庫效能瓶頸分析的時候，常被大家誤解為簡單的使用更為強勁的主機或者儲存來替換現有的裝置。
個人覺得這其中可能存在一個非常大的誤區。我們在談論基於硬體進行最佳化的時候，不能僅僅將資料庫使用的硬體劃分為主機和儲存兩部分，而是需要進一步對硬體進行更細的分解，至少也應該分解到如下範疇：
- 主機
- CPU：僅僅只能決定運算速度，及時是運算速度都還取決於與記憶體之間的匯流排頻寬以及記憶體本身的速度
- 記憶體：大小決定了所能緩衝的資料量，主要決定了熱點資料的訪問速度
- 磁碟：
- 大小：決定了你最終能存放多少資料量
- 轉速：決定了你每一次IO請求的延時時間，也就是決定了我們常說的IOPS和MBPS
- 數目：磁碟數目決定了
- 類型
- 機械：SAS or SATA or FC ？
- SSD：磁碟 or PCI卡？
- Raid卡：
- 緩衝：緩衝大小對資料寫入速度有較大影響，使用原則也會直接影響IO效率
- 電池：電池充放電策略會影響到瞬時IO的波動
- 其他：如匯流排頻寬等，決定了CPU與記憶體間資料轉送效率，這一點很多時候關注較少，但也可能會出現瓶頸
- 儲存
- 記憶體：存放裝置同樣也有記憶體，用來儲存前端主機訪問的熱點資料。儲存的記憶體大小同樣決定了熱點資料的訪問速度
- 磁碟：和主機磁碟類似
- 線路/環路頻寬：環路頻寬必須能夠匹配磁碟頻寬，至少不能少於磁碟所能輸出的能力，否則就想被堵在高速收費站等待通行的車輛一樣
- 網路
- 延時：不同的網路裝置其延時會有差異，對於 OLTP 裝置來說，延時自然是越小越好
- 輸送量：對於資料庫叢集來說，各個節點之間的網路輸送量可能直接決定叢集的處理能力
- iops：對於 OLTP 系統，資料轉送更多是以小IO多並發方式，有時候光有大頻寬並不一定能滿足需求
硬體角度所能提供的處理能力，一定是上面所列的多個方面（這裡僅僅只是主要部分，可能還有其他）共同決定的整體能力，任何一個方面出現瓶頸，都能導致整體效能上不去，也就是我們常說的木桶原理。
在以往的經驗中，最容易出現效能瓶頸的地方主要會出現在以下幾個方面：
- IO資源方面瓶頸
出現 IO 資源方面瓶頸的時候，主要表現在伺服器 iowait 很高，usr 佔比較少，系統響應較慢，資料庫中經常會存在大量執行狀態的 session。
遇到 IO 資源方面的瓶頸，我們可以使用的硬體層面最佳化方案主要就是：
- 增加記憶體加大可快取的資料量：這個方案能否達到效果取決於系統熱點資料的總量，畢竟記憶體的成本也是比較高的，而且單台裝置所能管理的記憶體量也是有限的
- 改善底層存放裝置的 IO 能力：如本文前面所述，底層儲存能力的改善同時取決於多個方面，既有單個磁碟本身的能力問題，也包括磁碟數目方面的策略，同時還受到儲存自身以及儲存和主機之間的頻寬節流設定。所以在最佳化底層儲存能力的同時需要同時考慮到這3方面的因素，做好總體分析和局部的平衡
- CPU資源方面瓶頸
當 CPU 方面資源遇到瓶頸的時候，主要表現在伺服器CPU利用率中 usr 所佔比例很高，iowait卻很小。這類問題大多出現在資料量並不是太大，同時又有足夠記憶體來對資料進行緩衝的應用情境。同時也是目前大多數中小網站所面臨的資料庫效能瓶頸。
當遇到 CPU 方面的資源瓶頸的時候，可能由兩個方面造成：
- 過多依賴資料庫進行邏輯運算：對於這種狀況，最好的最佳化方式是將運算儘可能從資料庫端遷移到應用端，降低資料庫主機的計算量。畢竟對有狀態的系統裝置（資料庫）進行擴容的成本遠高於無狀態類系統裝置（應用）。當然如果非要從資料庫端的硬體來解決問題，那就只有通過增加裝置CPU數目（如果支援），或者是使用CPU能力更為高端的主機來替換老主機
- 資料庫邏輯IO太大：對於這類狀況，從硬體角度來說能做的就只有提升CPU處理能力。要麼增加 CPU 數目（如果支援），要麼換CPU更強勁的主機。但是在這之前，還是建議先嘗試從應用角度最佳化看看是否能夠盡量降低非必要請求或者是減少每次請求的資料量。同時從資料庫角度針對 Schema結構以及索引進行相應的最佳化調整，儘可能讓完成一次請求所需要檢索的資料量更小，從而達到降低邏輯IO的目的
- 網路資源方面的瓶頸
一般來說應用與資料庫之間的網路互動所需的資源並不是非常大，所以這個環境遇到瓶頸的可能並不是非常大。但是在分布式的叢集環境中，各個資料庫節點之間的網路環境經常會稱為系統的瓶頸。
比較常見的情境如 MySQL Cluster 或者是 Oracle RAC 環境中，節點之間的資料交換網路環境的優劣可能直接影響到系統的整體處理能力，因為在節點間會存在大量的資料交換，都是依賴網路傳輸來完成。
在這樣的情境中，廉價一點的解決方案是通過 萬兆交換器 來替換現在常用的 千兆交換器 來提升網路處理能力降低網路延時。不過這個方案主要提升的是輸送量方面，對於延時方面的提升可能並不一定能滿足某些要求非常高的情境。這時候就該考慮使用更為昂貴但也更高效的方案：用 Infiniband 替換普通交換器來極大的降低網路方面所帶來的資料交換延時。
以上僅僅只針對主要類型的硬體資源瓶頸做了一些分析和相應可能的處理方式，歡迎大家一起探討，也可以包括目前比較“熱”的SSD。後面我可能還會再寫一篇關於 SSD 的文章，國內接觸 SSD 並將之正式用於核心產品環境的，可能比我更早人還是比較少的。
轉自 http://isky000.com/database/mysql-performance-tuning-hardware
