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系统来说，单表的大数据量取决于整个数据库的总数据量、相应的表结构以及服务器的硬件设置。