傳說InnoDB的數(shù)據(jù)量到了一定程度就會有一個很大的下滑。那么這個闕值究竟是是多少？來做一下測試吧！

1、調(diào)整my.cnf的參數(shù)如下：

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個線程并發(fā)，各執(zhí)行以下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個線程并發(fā)，各執(zhí)行以下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內(nèi)的數(shù)據(jù)量小于3000萬，則跳轉至3；反之結束壓測。

結果得到了30張圖，在這里就不貼了。可以看出，每秒能夠執(zhí)行的select量從12000(數(shù)據(jù)量100萬)緩步下降到7800(數(shù)據(jù)量3000萬)。這個性能下降主要是因為每次查詢可以得到的數(shù)據(jù)越來越多造成的，如果將SQL換成按主鍵索引，是否出現(xiàn)這種性能下降仍未可知。但是可以肯定的是，按照主鍵索引來查詢數(shù)據(jù)，即使出現(xiàn)性能下降也會比二級索引要更緩慢。

由于每條記錄都比較小，所以本次實驗的數(shù)據(jù)基本上全部在內(nèi)存中。在3000萬數(shù)據(jù)的范圍內(nèi)，未出現(xiàn)所謂的性能拐點。初步猜想，前人的實驗結果出現(xiàn)性能拐點，是因為內(nèi)存耗盡，MySQL需要從磁盤上讀取數(shù)據(jù)引起的。而這種性能拐點與MySQL本身的實現(xiàn)機制無關。

覺得文章有用？立即：

和朋友一起 共學習 共進步！

猜您喜歡

總結

以上是生活随笔為你收集整理的Mysql拐点_InnoDB select性能拐点测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。