上篇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