InnoDB insert性能拐點測試

　　上篇blog《InnoDB select性能拐點測試》測試了InnoDB select的性能拐點，本篇blog對insert的性能拐點做了一些對比研究。大家有興趣就關注一下吧!

　　1、調整my.cnf的參數如下：

　　innodb_file_per_table = 0

　　innodb_flush_log_at_trx_commit = 2

　　innodb_buffer_pool_size = 8G

　　innodb_file_io_threads = 4

　　重啟服務器，啟動mysqld

　　2、在test庫上建表：

　　CREATE TABLE `test` (

　　`ID` bigint(20) NOT NULL auto_increment,

　　`INT_A` int(11) default NULL,

　　`INT_B` int(11) default NULL,

　　`INT_C` int(11) default NULL,

　　`STRING_A` varchar(50) default NULL,

　　`STRING_B` varchar(250) default NULL,

　　`STRING_C` varchar(700) default NULL,

　　PRIMARY KEY (`ID`),

　　KEY `IDX_TEST_IA` (`INT_A`),

　　KEY `IDX_TEST_IB` (`INT_B`),

　　KEY `IDX_TEST_SA` (`STRING_A`,`INT_C`)

　　) ENGINE=InnoDB DEFAULT CHARSET=gbk

　　3、50個線程并發，各執行以下SQL 80萬次：

　　insert into test(INT_A, INT_B, INT_C, STRING_A, STRING_B, STRING_C) values(CEIL(RAND()*100000), CEIL(RAND()*100000), CEIL(RAND()*100000), random_string(CEIL(50*RAND())), random_string(CEIL(250*RAND())), random_string(CEIL(700*RAND())))

　　從以上圖可以看出，在4000萬的數據量內，InnoDB的insert效率是緩慢下降的，并沒有出現突降的現象。在上一篇blog中，我曾經提出一個猜想，“前人的實驗結果出現性能拐點，是因為內存耗盡，MySQL需要從磁盤上讀取數據引起的”。為了證實這個想法，需要限制InnoDB使用buffer，因為8G的buffer再加上8G的操作系統cache，需要的數據量太大了!于是進行了以下第二個對比試驗。

　　1、truncate table test

　　2、調整my.cnf的參數如下：

　　innodb_file_per_table = 0

　　innodb_flush_log_at_trx_commit = 2

　　innodb_flush_method = O_DIRECT

　　innodb_buffer_pool_size = 500M

　　innodb_file_io_threads = 4

　　重啟服務器，啟動mysqld

　　3、50個線程并發，各執行以下SQL 80萬次：

　　insert into test(INT_A, INT_B, INT_C, STRING_A, STRING_B, STRING_C) values(CEIL(RAND()*100000), CEIL(RAND()*100000), CEIL(RAND()*100000), random_string(CEIL(50*RAND())), random_string(CEIL(250*RAND())), random_string(CEIL(700*RAND())))

　　在以上圖中，可以很清楚得看到了性能拐點!性能在數據量達到750萬的時候出現了一個大大的降幅!那么，這個性能拐點是不是由buffer的設置引起的呢?再來做個實驗驗證一下!

　　1、truncate table test

　　2、調整my.cnf的參數如下：

　　innodb_file_per_table = 0

　　innodb_flush_log_at_trx_commit = 2

　　innodb_flush_method = O_DIRECT

　　innodb_buffer_pool_size = 2G

　　innodb_file_io_threads = 4

　　重啟服務器，啟動mysqld

　　3、50個線程并發，各執行以下SQL 80萬次：

　　insert into test(INT_A, INT_B, INT_C, STRING_A, STRING_B, STRING_C) values(CEIL(RAND()*100000), CEIL(RAND()*100000), CEIL(RAND()*100000), random_string(CEIL(50*RAND())), random_string(CEIL(250*RAND())), random_string(CEIL(700*RAND())))

　　性能突降的現象消失了!我們可以由此得出一個結論：以測試的表結構而言，4000萬的數據量以內，insert的性能是緩步下降的，并未出現性能拐點。然而過小的buffer設置會引起頻繁的交換，出現類似性能拐點的現象。結合之前的select性能測試，可以認為Innodb基本上不存在所謂的性能拐點。只要正確估計數據量，合理設置內存，就可以避免出現性能瓶頸。對于分布式MySQL系統來說，單表的最大數據量取決于整個數據庫的總數據量、相應的表結構以及服務器的硬件設置。

原文轉自：http://www.anti-gravitydesign.com