以下的環境具備一定的代表性，可以說是中小企業一般配置和工作環境。希望通過本文能讓大家理解Linux下MySQL數據庫性能調優方法。
硬件准備環境：
硬盤： 16塊 SAS 15K RAID5 帶512MCache
CPU： AMD 4核兩顆
內存： 16G
軟件環境：
操作系統： RedHat AS4.6 2.6.9-67.ELsmp MySQL: 5.0
下面分別根據不同場景進行性能調優：
使用場景A： 寫操作（插入/查詢/刪除）密集，而且數據容量遠遠超硬件准備環境：
硬盤： 16塊 SAS 15K RAID5 帶512MCache
CPU： AMD 4核兩顆
內存： 16G
軟件環境
操作系統： RedHat AS4.6 2.6.9-67.ELsmp
MySQL: 5.0
下面分別根據不同場景進行性能調優：
使用場景A：
寫操作（插入/查詢/刪除）密集，而且數據容量遠遠超過內存的大小（最小是200G以上，甚至更大到1.5T以上）， 每秒需要以千為單位的事務操作
數據可靠性要求不高，允許丟幾條記錄（硬件出故障時）
優化方式：
在這種情況下，數據庫的Cache基本上命中率是非常低的，對數據庫的操作基本上就是對磁盤進行操作， 因此側重點應該是對磁盤相關優化。
首先是考慮數據庫存儲引擎，由於涉及插入/刪除/查詢等操作，而且要支持事務，因此考慮使用InnoDB存儲引擎，不考慮MyIsam原因是該存儲引擎是表級鎖，有數據刪除時會非常慢。
設置合適的MySQL 參數，由於有16G內存，因此參數設置如下
innodb_buffer_pool_size=8G innodb_additional_mem_pool_size = 800M, innodb_log_buffer_size = 4M innodb_log_file_size = 500M innodb_log_files_in_group = 4 log-bin 因為使用主備復制，因此需要打開Log-Bin，這裡就涉及一個sync-bin的概念，缺省情況下，sync-bin 在MySQL中是關閉的，但存在一個風險，因為寫日志沒有刷新到硬盤中去的話，日志是寫在操作系統的文件系統裡的Cache中，這樣若機器斷電，那麼日志信息將部分丟失。為了減少數據丟失，我們測試了sync-bin=1,sync-bin=5和sync-bin=20，三種情況，sync-bin=1的情況下，丟失數據最壞概率是丟一個事務的數據，但性能非常差；設置sync-bin=5的情況下，性能可以提高1倍左右；設置sync-bin=20時，性能比sync-bin=5又可以提高1倍，設置大於20的值，基本上相差不大，性能提高不了多少，最壞20個事務數據丟失是在我們的允許范圍之內，因此設置20是個合理的值，這個值具體取決於你的系統能夠最壞允許丟少的事務數據。
若你的系統對數據丟失不於考慮，可以關閉sync-bin,這時數據刷新到硬盤完全取決於操作系統的配置，相關的配置參數有如下：
/proc/sys/vm/dirty_ratio 這 個參數控制一個進程在文件系統中的文件系統寫緩沖區的大小，單位是百分比，表示系統內存的百分比，表示當一個進程中寫緩沖使用到系統內存多少的時候，再有 磁盤寫操作時開始向磁盤寫出數據。增大之會使用更多系統內存用於磁盤寫緩沖，也可以極大提高系統的寫性能。但是，當你需要持續、恆定的寫入場合時，應該降 低其數值，一般缺省是 40。更新方法
echo 30 >/proc/sys/vm/dirty_ratio (或則修改/etc/sysctl.conf文件，增加sys.vm.dirty_ratio=30 重起機器)
/proc/sys/vm/dirty_background_ratio 這個參數控制文件系統的pdflush進程，在何時刷新磁盤。單位是百分比，表示系統總內存的百分比，意思是當磁盤的髒數據緩沖到系統內存多少的時候，pdflush開始把髒數據刷新到磁盤。增大會使用更多系統內存用於磁盤寫緩沖，也可以極大提高系統的寫性能。但是，當你需要持續、恆定的寫入場合時，應該降低其數值，一般缺省是10。
/proc/sys/vm/dirty_writeback_centisecs Pdflush寫後台進程每隔多久被喚醒並執行把髒數據寫出到硬盤。單位是 1/100 秒。缺省數值是500，也就是 5 秒。如果你的系統是持續地寫入動作，那麼實際上還是降低這個數值比較好，這樣可以把尖峰的寫操作削平成多次寫操作。設置方法如下：
echo 200 >/proc/sys/vm/dirty_writeback_centisecs /proc/sys/vm/dirty_expire_centisecs 這個參數聲明Linux內核寫緩沖區裡面的髒數據多“舊”了之後，pdflush進程就開始考慮寫到磁盤中去。單位是 1/100秒。缺省是 30000，也就是 30 秒的數據就算舊了，將會刷新磁盤。對於特別重載的寫操作來說，這個值適當縮小也是好的，但也不能縮小太多，因為縮小太多也會導致IO提高太快。建議設置為 1500，也就是15秒算舊。
echo 1500 >/proc/sys/vm/ dirty_expire_centisecs 因此若沒有調整這些參數，全部以缺省值，而且關閉sync-bin的話，那麼最多丟失的數據是：
5秒種（dirty_writeback_centisecs）之內的，小於1.6G的數據（dirty_background_ratio，16G/10=1.6G）
當然，實際上5秒之內不太可能寫1.6G的數據，因此最壞就是5秒鐘之內的數據丟失。因此若要關閉sync-bin，又不想丟失太多數據的話，可以通過調整dirty_writeback_centisecs這個參數，如調整到200（2秒），這樣最多就丟2秒鐘的數據。又可以提高數據的寫能力。
MySQL裡還有一個參數可以調整，提高數據庫的寫能力，那就是
innodb_flush_log_at_trx_commit 這個參數默認是1，即每次事務Commit時，都刷新日志，以免數據丟失。因為我們的系統允許丟失少量數據，因此可以把innodb_flush_log_at_trx_commit設置為2，允許丟失一個事務的數據，經測試，發現2可以提高25%左12下一頁