在可擴展性方面，客戶的要求變得越來越多，功能列表上經(jīng)常會出現(xiàn)20條、50條甚至多達100多條要求，但總的來說，我們可以把它們縮短為五個大類，通過五條途徑來解決可擴展性問題：

1. 調(diào)整查詢操作

對查詢進行優(yōu)化能夠讓你付出最少的精力就得到最多的成果。將查詢功能完善的發(fā)揮出來，達到業(yè)務需求，不會被過多的流量和過重的載荷壓倒。這就是為什么我們經(jīng)?？匆娍蛻襞龅降穆闊┰絹碓蕉?，隨著他們網(wǎng)站的訪問量越來越大，可擴展性的挑戰(zhàn)也變得越來越嚴重，這就是問題的所在。對網(wǎng)站角落里那些不常用的頁面做查詢優(yōu)化是并不必要的，那些頁面并不會收到真實世界的流量。根據(jù)反映對網(wǎng)絡應用做一定的調(diào)整是很普遍的做法，而且效果很好。

查詢優(yōu)化需要啟用緩慢查詢?nèi)罩静⑶也粩嘤^察。使用mk-query-digest這個Maatkit套件中的強大工具來分析日志，而且要確定設置了log_queries_not_using_indexes標簽。一旦你發(fā)現(xiàn)某個查詢嚴重占用資源，那就要優(yōu)化它。使用EXPLAIN解釋機制，使用profiler，觀察索引的使用情況，創(chuàng)建失蹤的索引，理解它是怎么進行添加和排序的。

2.使用Master-Master復制

Master-Master的active-passive復制模式，或者稱為循環(huán)復制，不僅能帶來高可用性，也能夠帶來高度的可擴展性。這是因為你能夠即刻給你的應用分配到一塊只讀的從屬盤。許多網(wǎng)絡應用都按照80/20的規(guī)律來分割，80%的活動用來進行讀取或SELECT，剩下的分配給INSERT和UPDATE。配置你的應用或者進行重新架構，把讀取需要的流量發(fā)送到從盤，這樣做是可行的，這種類型的橫向可擴展能力可以進一步延伸，在必要時能夠附加更多塊只讀從盤。

3. 使用存儲

這聽起來是很基礎的東西，也很直接，但是經(jīng)常會被忽視，你至少應該確認設置了這些：

•  innodb_buffer_pool_size
•  key_buffer_size (MyISAM索引緩存)
•  query_cache_size – 使用大型SMP時需要小心
•  thread_cache & table_cache
•  innodb_log_file_size & innodb_log_buffer_size
•  sort_buffer_size, join_buffer_size, read_buffer_size, read_rnd_buffer_size
•  tmp_table_size & max_heap_table_size

4. 磁盤讀取的RAID

你的數(shù)據(jù)庫下面是什么?不知道嗎，請找出來。你是在用RAID 5嗎?這對于性能來說可是一個巨大的阻礙。RAID5的插入和更新操作速度很慢，而且如果你丟失了一塊硬盤，RAID 5在重建時幾乎無能為力。RAID 5實在是太慢了，那么應該用什么代替它呢?用RAID 10做鏡像和分段，這就可以充分利用你的服務器或機箱里的所有硬盤了。即使你的內(nèi)存能夠容納下整個數(shù)據(jù)庫，依然需要對硬盤進行許多讀取操作。為什么呢?因為比如排序操作需要重新安排行列，群組和聯(lián)接等等也一樣，還有添加交易日志等等這些都是磁盤I/O操作。

5. 調(diào)整Key參數(shù)

另外，有些附加的參數(shù)也可以用來提高性能：

innodb_flush_log_at_trx_commit=2

它可以極大的提升insert和update的速度，只是在清除innodb日志緩沖區(qū)時有點偷懶。你可以對它多做些研究，但大多數(shù)情況下是非常值得推薦的。

innodb_file_per_table

innodb開發(fā)就像Oracle，存儲方面使用的是tablespace模式。顯然內(nèi)核開發(fā)者們做的并不完善，因為使用單獨tablespace的默認設置就會出現(xiàn)性能瓶頸。這個參數(shù)設置可以幫助innodb為每個表創(chuàng)建tablespace和數(shù)據(jù)文件，就像MyISAM所做的一樣。

原文地址：http://sql.dzone.com/news/5-ways-boost-mysql-scalability