在本章之前的所有部分都是介紹的整個系統中的軟體環境對系統效能的影響，這一節我們將從系統硬體環境來分析對資料庫系統的影響，並從資料庫伺服器主機的角度來做一些針對性的優化建議。
任何乙個系統的硬體環境都會對起效能起到非常關鍵的作用，這一點我想每一位讀者朋友都是非常清楚的。而資料庫應用系統環境中，由於資料庫自身的特點和在系統中的角色決定了他在整個系統中是最難以擴充套件的部分。所以在大多數環境下，資料庫伺服器主機（或者主機集群）的效能在很大程度上決定了整個應用系統的效能。
既然我們的資料庫主機資源如此重要，肯定很多讀者朋友會希望知道，資料庫伺服器主機的各部分硬體到底誰最重要，各部分對整體效能的影響各自所佔的比例是多少，以便能夠根據這些比例選取合適的主機機型作為資料庫主機。但是我只能很遺憾的告訴大家，沒有任何乙個定律或者法則可以很準確的給出這個答案。
當然，大家也不必太沮喪。雖然沒有哪個法則可以準確的知道我們到底該如何選配乙個主機的各部分硬體，但是根據應用型別的不同，總體上還是有乙個可以大致遵循的原則可以參考的。
首先，資料庫主機是訪問資料的地方，那麼其io操作自然不會少，所以資料庫主機的io效能肯定是需要最優先考慮的乙個因素，這一點不管是什麼型別的資料庫應用都是適用的。不過，這裡的io效能並不僅僅只是指物理的磁碟io，而是主機的整體io效能，是主機整個io系統的總體io效能。而io效能本身又可以分為兩類，一類是每秒可提供的io訪問次數，也就是我們常說的iops數量，還有一種就是每秒的io總流量，也就是我們常說的io吞吐量。在主機中決定io效能部件主要由磁碟和記憶體所決定，當然也包括各種與io相關的板卡。
其次，由於資料庫主機和普通的應用程式伺服器相比，資源要相對集中很多，單台主機上所需要進行的計算量自然也就比較多，所以資料庫主機的cpu處理能力也不能忽視。
最後，由於資料庫負責資料的儲存，與各應用程式的互動中傳遞的資料量比其他各類伺服器都要多，所以資料庫主機的網路裝置的效能也可能會成為系統的瓶頸。
由於上面這三類部件是影響資料庫主機效能的最主要因素，其他部件成為效能瓶頸的機率要小很多，所以後面我們通過對各種型別的應用做乙個簡單的分析，再針對性的給出這三類部件的基本選型建議。
對於各種資料庫系統環境中大家最常見的oltp系統，其特點是併發量大，整體資料量比較多，但每次訪問的資料比較少，且訪問的資料比較離散，活躍資料佔總體資料的比例不是太大。對於這類系統的資料庫實際上是最難維護，最難以優化的，對主機整體效能要求也是最高的。因為他不僅訪問量很高，資料量也不小。
針對上面的這些特點和分析，我們可以對oltp的得出乙個大致的方向。
雖然系統總體資料量較大，但是系統活躍資料在資料總量中所佔的比例不大，那麼我們可以通過擴大記憶體容量來盡可能多的將活躍資料cache到記憶體中；
雖然io訪問非常頻繁，但是每次訪問的資料量較少且很離散，那麼我們對磁碟儲存的要求是iops表現要很好，吞吐量是次要因素；
併發量很高，cpu每秒所要處理的請求自然也就很多，所以cpu處理能力需要比較強勁；
雖然與客戶端的每次互動的資料量並不是特別大，但是網路互動非常頻繁，所以主機與客戶端互動的網路裝置對流量能力也要求不能太弱。
用於資料分析的olap系統的主要特點就是資料量非常大，併發訪問不多，但每次訪問所需要檢索的資料量都比較多，而且資料訪問相對較為集中，沒有太明顯的活躍資料概念。
基於olap系統的各種特點和相應的分析，針對olap系統硬體優化的大致策略如下：
資料量非常大，所以磁碟儲存系統的單位容量需要盡量大一些；
單次訪問資料量較大，而且訪問資料比較集中，那麼對io系統的效能要求是需要有盡可能大的每秒io吞吐量，所以應該選用每秒吞吐量盡可能大的磁碟；
雖然io效能要求也比較高，但是併發請求較少，所以cpu處理能力較難成為效能瓶頸，所以cpu處理能力沒有太苛刻的要求；
雖然每次請求的訪問量很大，但是執行過程中的資料大都不會返回給客戶端，最終返回給客戶端的資料量都較小，所以和客戶端互動的網路裝置要求並不是太高；
此外，由於olap系統由於其每次運算過程較長，可以很好的並行化，所以一般的olap系統都是由多台主機構成的乙個集群，而集群中主機與主機之間的資料互動量一般來說都是非常大的，所以在集群中主機之間的網路裝置要求很高。
除了以上兩個典型應用之外，還有一模擬較特殊的應用系統，他們的資料量不是特別大，但是訪問請求及其頻繁，而且大部分是讀請求。可能每秒需要提供上萬甚至幾萬次請求，每次請求都非常簡單，可能大部分都只有一條或者幾條比較小的記錄返回，就比如基於資料庫的dns服務就是這樣型別的服務。
雖然資料量小，但是訪問極其頻繁，所以可以通過較大的記憶體來cache住大部分的資料，這能夠保證非常高的命中率，磁碟io量比較小，所以磁碟也不需要特別高效能的；
併發請求非常頻繁，比需要較強的cpu處理能力才能處理；
雖然應用與資料庫互動量非常大，但是每次互動資料較少，總體流量雖然也會較大，但是一般來說普通的千兆網絡卡已經足夠了。
在很多人看來，效能的根本決定因素是硬體效能的好壞。但實際上，硬體效能只能在某些階段對系統效能產生根本性影響。當我們的cpu處理能力足夠的多，io系統的處理能力足夠強的時候，如果我們的應用架構和業務實現不夠優化，乙個本來很簡單的實現非得繞很多個彎子來回互動多次，那再強的硬體也沒有用，因為來回的互動總是需要消耗時間。尤其是有些業務邏輯設計不是特別合理的應用，資料庫schema設計的不夠合理，乙個任務在系統中又被分拆成很多個步驟，每個步驟都使用了非常複雜的query語句。
筆者曾經就遇到過這樣乙個系統，該系統是購買的某知名廠商的乙個專案管理軟體。該系統最初執行在一台dell2950的pcserver上面，使用者一直抱怨系統響應很慢，但我從伺服器上面的狀態來看系統並繁忙（系統併發不是太大）。後來使用者強烈要求通過更換硬體設施來提公升系統效能，雖然我一直反對，但最後在管理層的要求下，更換成了一台sun的s880小型機，主機cpu的處理能力至少是原來機器的3倍以上，儲存系統也從原來使用本地磁碟換成使用emc的中斷儲存cx300。可在試用階段，發現系統整體效能沒有任何的提公升，最終還是取消了更換硬體的計畫。
所以，在應用系統的硬體配置方面，我們應該要以乙個理性的眼光來看待，只有合適的才是最好的。並不是說硬體資源越好，系統效能就一定會越好。而且，硬體系統本身總是有乙個擴充套件極限的，如果我們一味的希望通過公升級硬體效能來解決系統的效能問題，那麼總有一天將會遇到無法逾越的瓶頸。到那時候，就算有再多的錢去砸也無濟於事了。
** 《mysql效能調優與架構設計》
Spring 事物對系統效能影響
背景 公司使用的自己封裝的分庫分表的中介軟體，配合spirng的事物，實現資料庫訪問功能。優化前的針對某介面的tps只有30左右 介面呼叫spring事物的偽 public void a public void b 事物配置針對方法a method name a propagation requir...
Query語句對系統效能的影響
需求 取出某個group 假設id為1 下的使用者編號id,使用者暱稱 nick name 並按照加入組的時間 user group.gmt create 來進行倒序排列，取出前20個 解決方案一 select id,nick name from user,user group where user...
陣列Cache使用方式對系統效能的影響
esxi等虛擬機器的儲存io會因為陣列的cache而效能迥異。提及磁碟陣列，大家可能都不會感到陌生。這項技術利用多塊磁碟組合成乙個邏輯磁碟，資料的讀寫也按照不同的分散排列方式，取自或儲存於不同的磁碟中。該技術所帶來的好處是它不僅可以利用多塊硬碟為系統組建出乙個更大的儲存空間，更重要的是它可以提高磁碟...