在過往與很多人的交流過程中發現，在談到基於硬體來進行資料庫效能瓶頸分析的時候，常被大家誤解為簡單的使用更為強勁的主機或者儲存來替換現有的裝置。
個人覺得這其中可能存在乙個非常大的誤區。我們在談論基於硬體進行優化的時候，不能僅僅將資料庫使用的硬體劃分為主機和儲存兩部分，而是需要進一步對硬體進行更細的分解，至少也應該分解到如下範疇：
raid卡：
其他：如匯流排頻寬等，決定了cpu與記憶體間資料傳輸效率，這一點很多時候關注較少，但也可能會出現瓶頸
儲存 網路
硬體角度所能提供的處理能力，一定是上面所列的多個方面（這裡僅僅只是主要部分，可能還有其他）共同決定的整體能力，任何乙個方面出現瓶頸，都能導致整體效能上不去，也就是我們常說的木桶原理。
在以往的經驗中，最容易出現效能瓶頸的地方主要會出現在以下幾個方面：
cpu資源方面瓶頸
當 cpu 方面資源遇到瓶頸的時候，主要表現在伺服器cpu利用率中 usr 所佔比例很高，iowait卻很小。這類問題大多出現在資料量並不是太大，同時又有足夠記憶體來對資料進行快取的應用場景。同時也是目前大多數中小**所面臨的資料庫效能瓶頸。
當遇到 cpu 方面的資源瓶頸的時候，可能由兩個方面造成：
網路資源方面的瓶頸
一般來說應用與資料庫之間的網路互動所需的資源並不是非常大，所以這個環境遇到瓶頸的可能並不是非常大。但是在分布式的集群環境中，各個資料庫節點之間的網路環境經常會稱為系統的瓶頸。
比較常見的場景如 mysql cluster 或者是 oracle rac 環境中，節點之間的資料交換網路環境的優劣可能直接影響到系統的整體處理能力，因為在節點間會存在大量的資料交換，都是依賴網路傳輸來完成。
在這樣的場景中，廉價一點的解決方案是通過 萬兆交換機 來替換現在常用的 千兆交換機 來提公升網路處理能力降低網路延時。不過這個方案主要提公升的是吞吐量方面，對於延時方面的提公升可能並不一定能滿足某些要求非常高的場景。這時候就該考慮使用更為昂貴但也更高效的方案：用 infiniband 替換普通交換機來極大的降低網路方面所帶來的資料交換延時。
MySQL資料庫效能優化之硬體優化
在過往與很多人的交流過程中發現，在談到基於硬體來進行資料庫效能瓶頸分析的時候，常被大家誤解為簡單的使用更為強勁的主機或者儲存來替換現有的裝置。個人覺得這其中可能存在乙個非常大的誤區。我們在談論基於硬體進行優化的時候，不能僅僅將資料庫使用的硬體劃分為主機和儲存兩部分，而是需要進一步對硬體進行更細的分解...
MySQL資料庫效能優化 硬體瓶頸分析
在過往與很多人的交流過程中發現，在談到基於硬體來進行資料庫效能瓶頸分析的時候，常被大家誤解為簡單的使用更為強勁的主機或者儲存來替換現有的裝置。個人覺得這其中可能存在乙個非常大的誤區。我們在談論基於硬體進行優化的時候，不能僅僅將資料庫使用的硬體劃分為主機和儲存兩部分，而是需要進一步對硬體進行更細的分解...
MySQL 資料庫效能優化之SQL優化
hosted on dreamhost 可以通過我的折扣碼imysqler獲得優惠折扣 有人反饋之前幾篇文章過於理論缺少實際操作細節，這篇文章就多一些可操作性的內容吧。盡量避免 select 很多人看到這一點後覺得比較難理解，上面不是在誤區中剛剛說 select 子句中字段的多少並不會影響到讀取的資...