目前web2.0的程序，很大瓶頸是數(shù)據(jù)庫的吞度量。不過，如何才能確定系統(tǒng)的瓶頸是數(shù)據(jù)庫呢，因為只有確定數(shù)據(jù)庫是整個系統(tǒng)的瓶頸，我們才有必要去優(yōu)化他，畢竟，還有這么多需求等待我們去做。

　　如何確定數(shù)據(jù)庫是瓶頸?

　　1 如果程序設計良好，有一個數(shù)據(jù)庫操作邏輯層，可以從這個層的統(tǒng)計數(shù)據(jù)看到每個請求花費的時間，如果平均時間已經(jīng)不能讓你容忍的話，數(shù)據(jù)庫已經(jīng)是瓶頸了。

　　2 在數(shù)據(jù)庫的服務器上使用top命令，看看mysql服務器占用資源的情況，看看機子的平均負載。

　　如果服務器的平均負載已經(jīng)很高，mysql占用了塊100%的cpu資源，說明mysql服務器很忙了。

　　3 在數(shù)據(jù)庫服務器上使用iostat命令，看看磁盤IO，如果block住的操作比較多的話，說明數(shù)據(jù)庫操作還是過于頻繁了，磁盤都響應不急了。

　　4 建議打開mysql的慢查詢日志，這樣grep select看一下日志中的慢查詢的數(shù)量，如果數(shù)量較多，說明慢查詢的數(shù)量很多，需要進行調整了。

　　5 如果有一天數(shù)據(jù)庫無法插入了，需要檢查一下數(shù)據(jù)庫表是不是過大了。32位的操作系統(tǒng)上一個表最大的容量是2^32這么大。不過還是建議增加一個數(shù)據(jù)庫操作的邏輯層，在數(shù)據(jù)庫操作的前后記錄下操作的時間，進行統(tǒng)計上報，利用監(jiān)控程序來報警相關負責人，這樣可以及早的知道數(shù)據(jù)庫是瓶頸，提前做出優(yōu)化。

　　知道數(shù)據(jù)庫是瓶頸了，如何來進行優(yōu)化呢?

　　1 我們第一個想到是看看數(shù)據(jù)庫的容量是不是太大了，如果數(shù)據(jù)庫表太大的話，索引文件也會比較大，每次的更新操作就會更加的費時。需要考慮進行分庫和分表了。

　　分庫分表按照一定的規(guī)則來對數(shù)據(jù)庫中的記錄進行分區(qū)來存儲，一方面可以做到一定的負載均衡，將請求平分下來，每個區(qū)段去獨自承受;另一方面，分庫分表可以使我們存儲和操作更多的數(shù)據(jù)。

　　不過分庫分表需要多之前基于單庫的程序進行修改，存在一定的風險，因此，在程序設計之初就應該考慮到分庫分表的需要，最好是將數(shù)據(jù)庫操作層獨立出來，便于擴展和更改。

　　2 如果數(shù)據(jù)庫表不是很大，但是查詢慢的話，我們需要檢查一下我們的sql查詢語句，利用mysql的explain語句看看是不是使用了索引，如果沒有使用索引，那我們需要在相應的字段上建上索引，反復的使用explain，尋找到個一個合適的索引。

　　在建索引時需要考慮：

　　1)數(shù)據(jù)庫的索引要做到越少越好。

　　因為每次更新都需要更新索引，索引過多就會降低寫入的速度。

　　2)最窄的字段放在鍵的左邊。

　　這樣提高了索引中每一個點的基數(shù)，帶來更好的索引讀寫性能。

　　3)盡量避免file sort排序、臨時表和表掃描。

　　對于大表，全表掃描會導致大量的磁盤IO的操作，會導致操作非常的緩慢。

　　4)對于大表，盡量不要將索引建在字符串類型的列上，字符串的匹配是很費時的，需要付出很高的性能代價，如果一定有必要，建議對字符串列進行hash后取一個整形的值來進行索引。

　　3 如果更新操作有點慢，而讀操作的響應要求不需要很及時的話，可以考慮利用mysql的主從熱備來分擔讀寫的壓力。

　　畢竟對數(shù)據(jù)庫的操作，寫少讀多。因此，我們將對數(shù)據(jù)庫的寫操作放到mysql的主服務器上，利用mysql的熱備，我們在備份的數(shù)據(jù)庫服務器上進行讀操作，由于可以有多個熱備mysql，于是可以將讀操作分布在多個熱備上面，從而將讀操作均衡開來，提高讀操作的性能。

　　4 緩存的使用

　　緩存是一切后臺程序的根本，因為80%的請求是對應20%的數(shù)據(jù)，我們只需要少量的內存將20%的數(shù)據(jù)緩存起來，就可以大大的滿足我們系統(tǒng)需求，何樂而不為呢。

　　1)mysql設置中盡量增加key cache，thread cache、查詢的cache。

　　2)在應用程序層增加一個memcached這樣的通用cache。

　　3)對于少量數(shù)據(jù)，但是操作頻繁的表使用mysql提供的內存heap表，可以獲得極高的寫入和讀取速度。

　　5 數(shù)據(jù)庫的設計上進行優(yōu)化

　　對于傳統(tǒng)的數(shù)據(jù)庫設計我們講究建模范式，避免數(shù)據(jù)的冗余從而導致臟數(shù)據(jù)。然而在我們實際的應用中需要根據(jù)情況來使用第三范式的一些規(guī)則，對于一些頻繁需要在多個地方出現(xiàn)的數(shù)據(jù)，如同一個論壇這種用戶和主題以及回復等有關聯(lián)的應用中，如果我們將用戶同主題和回復分開來存儲，每次查詢一下一篇文章或者一個回復的情況都需要對用戶表和主題表或者回復表進行聯(lián)查，如果數(shù)據(jù)量小的話，這樣聯(lián)查的性能還是可以接受的，如果表大一點，上了3、4十萬以上的數(shù)據(jù)，聯(lián)查的速度就會比較慢了。

　　該范式化的地方需要進行范式化，但是還是需要根據(jù)情況來設計我們的表，從而達到性能和良好設計的折中。

　　其它的話：

　　1 對于數(shù)據(jù)庫的操作建議分層處理，至少分為兩層，一層是數(shù)據(jù)庫操作的邏輯層，一層是數(shù)據(jù)庫的cache層。

　　從一開始就考慮如此，可以很方便在未來對數(shù)據(jù)庫進行劃分部署、分庫分表擴展。

　　2 增加mysql的監(jiān)控，監(jiān)控mysql的慢查詢日志，監(jiān)控mysql的請求情況。

　　3 根據(jù)自己的需要來選擇mysql的存儲引擎。

　　myisam有較高的讀寫速度，但是由于表鎖定，不能同時進行快速的讀和寫。

　　innodb支持事務，提供了行級的鎖，但是為了使用事務，表空間會比較大，而且不支持全文索引。

　　heap將表放到內存中，適合與表小而需要頻繁操作的情況，如用戶信息，其讀寫很快，但是不是持久的，需要自己來寫工具讓其持久。

　　4 mysql服務器的一些狀態(tài)檢測的命令。

　　show slave status：可以看到主從同步的情況。

　　show [full] processlist：可以看到mysql服務器的請求情況，如果發(fā)現(xiàn)lock情況很多，需要注意了。

　　show status：可以看到mysql服務器的各種請求情況。