在過往與很多人的交流過程中發現，在談到基於硬件來進行數據庫性能瓶頸分析的時候，常被大家誤解為簡單的使用更為強勁的主機或者存儲來替換現有的設備。
個人覺得這其中可能存在一個非常大的誤區。我們在談論基於硬件進行優化的時候，不能僅僅將數據庫使用的硬件划分為主機和存儲兩部分，而是需要進一步對硬件進行更細的分解，至少也應該分解到如下范疇：
- 主機
- 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