快捷導(dǎo)航

my.cnf參數(shù)配置實(shí)現(xiàn)InnoDB引擎性能優(yōu)化

更新時(shí)間：2017年05月21日 10:28:13 作者：linux_c_coding_man

目前來說：InnoDB是為Mysql處理巨大數(shù)據(jù)量時(shí)的最大性能設(shè)計(jì)。它的CPU效率可能是任何其它基于磁盤的關(guān)系數(shù)據(jù)庫(kù)引擎所不能匹敵的。在數(shù)據(jù)量大的網(wǎng)站或是應(yīng)用中Innodb是倍受青睞的。另一方面，在數(shù)據(jù)庫(kù)的復(fù)制操作中Innodb也是能保證master和slave數(shù)據(jù)一致有一定的作用。

在網(wǎng)上看了無(wú)數(shù)的my.cnf的配置，大多數(shù)提到的配置無(wú)外乎這幾個(gè)：

1. innodb_buffer_pool_size
2. innodb_log_file_size
3. innodb_log_buffer_size
4. innodb_flush_log_at_trx_commit

然后自己寫了兩個(gè)例子，一個(gè)單線程的，一個(gè)多線程的來通過改變配置參數(shù)來測(cè)試是否提高了性能。結(jié)果是只有innodb_flush_log_at_trx_commit可以提高性能，對(duì)于1,2,3參數(shù)無(wú)論是開其中某一個(gè)，還是三個(gè)同時(shí)調(diào)節(jié)都沒有影響到測(cè)試性能。我想了下，可能是我的測(cè)試數(shù)據(jù)量還不夠大造成的，后續(xù)有條件了再更大的數(shù)據(jù)量測(cè)試一下這3個(gè)參數(shù)。

這里詳細(xì)說一下innodb_flush_log_at_trx_commit：

如果innodb_flush_log_at_trx_commit設(shè)置為0，log buffer將每秒一次地寫入log file中，并且log file的flush(刷到磁盤)操作同時(shí)進(jìn)行。該模式下，在事務(wù)提交的時(shí)候，不會(huì)主動(dòng)觸發(fā)寫入磁盤的操作。
如果innodb_flush_log_at_trx_commit設(shè)置為1，每次事務(wù)提交時(shí)MySQL都會(huì)把log buffer的數(shù)據(jù)寫入log file，并且flush(刷到磁盤)中去。
如果innodb_flush_log_at_trx_commit設(shè)置為2，每次事務(wù)提交時(shí)MySQL都會(huì)把log buffer的數(shù)據(jù)寫入log file。但是flush(刷到磁盤)操作并不會(huì)同時(shí)進(jìn)行。該模式下，MySQL會(huì)每秒執(zhí)行一次 flush(刷到磁盤)操作。

結(jié)果：

當(dāng)設(shè)置為0，該模式速度最快，但不太安全，mysqld進(jìn)程的崩潰會(huì)導(dǎo)致上一秒鐘所有事務(wù)數(shù)據(jù)的丟失。
當(dāng)設(shè)置為1，該模式是最安全的，但也是最慢的一種方式。在mysqld 服務(wù)崩潰或者服務(wù)器主機(jī)crash的情況下，binary log 只有可能丟失最多一個(gè)語(yǔ)句或者一個(gè)事務(wù)。
當(dāng)設(shè)置為2，該模式速度較快，也比0安全，只有在操作系統(tǒng)崩潰或者系統(tǒng)斷電的情況下，上一秒鐘所有事務(wù)數(shù)據(jù)才可能丟失。

注意：由于進(jìn)程調(diào)度策略問題,這個(gè)“每秒執(zhí)行一次 flush(刷到磁盤)操作”并不是保證100%的“每秒”。

結(jié)論：innodb_flush_log_at_trx_commit設(shè)置為0或者2的時(shí)候速度差不多，兩者都比設(shè)置為1的時(shí)候快很多。

這里又讓我想到了InnoDB和MyISAM引擎的區(qū)別，InnoDB的優(yōu)勢(shì)在于并發(fā)處理情況下比MyISAM快。而我的線程池?cái)?shù)量是根據(jù)cpu的線程數(shù)來設(shè)定的，然后我把線程池的數(shù)量設(shè)置比cpu線程數(shù)大，更大，再大，結(jié)果我的測(cè)試程序性能又提高了，我醉了，原來是我對(duì)線程池的理解太淺薄了。線程池的最優(yōu)大小

您可能感興趣的文章: