传说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本身的实现机制无关。

建议继续学习：

1. Innodb IO优化－配置优化    (阅读：6627)
2. Innodb分表太多或者表分区太多，会导致内存耗尽而宕机    (阅读：6131)
3. Innodb 表和索引结构    (阅读：4774)
4. 简单js+css实现模拟自定义select样式    (阅读：4416)
5. Innodb如何使用内存    (阅读：4002)
6. InnoDB线程并发检查机制    (阅读：4084)
7. 快速预热Innodb Buffer Pool的方法    (阅读：3961)
8. 学习libevent的select模型    (阅读：3849)
9. InnoDB的缓存替换策略及其效果    (阅读：3638)
10. 多版本并发控制：PostgreSQL vs InnoDB    (阅读：3631)