传说InnoDB的数据量到了一定程度就会有一个很大的下滑。那么这个阙值究竟是是多少？来做一下测试吧！
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 2万次：
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())))
4、50个线程并发，各执行以下SQL 20万次：
select count(test.INT_A) from test, (select CEIL(RAND()*100000) as rand_zyy) b where test.INT_A = b.rand_zyy
在此期间，每10秒记录一次com_select的变化
5、如果test内的数据量小于3000万，则跳转至3；反之结束压测。
结果得到了30张图，在这里就不贴了。可以看出，每秒能够执行的select量从12000（数据量100万）缓步下降到7800（数据量3000万）。这个性能下降主要是因为每次查询可以得到的数据越来越多造成的，如果将SQL换成按主键索引，是否出现这种性能下降仍未可知。但是可以肯定的是，按照主键索引来查询数据，即使出现性能下降也会比二级索引要更缓慢。
由于每条记录都比较小，所以本次实验的数据基本上全部在内存中。在3000万数据的范围内，未出现所谓的性能拐点。初步猜想，前人的实验结果出现性能拐点，是因为内存耗尽，MySQL需要从磁盘上读取数据引起的。而这种性能拐点与MySQL本身的实现机制无关。