MySql系列一：建索引

標籤：重要   auto   簡單   單列   效能   rem   prim   bubuko   區分   

本文主要目的是測試單列是否應該建立索引，並以查詢時間和掃描行數作為參考依據。mysql版本5.5.20

一：建表

CREATE TABLE `record` (  `id` int(11) NOT NULL AUTO_INCREMENT,  `openid` varchar(63) NOT NULL,  `tagId` int(11) DEFAULT NULL,  PRIMARY KEY (`id`),  KEY `idx_openid` (`openid`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8;

 

二：插入資料

向record表中匯入20萬測試資料

 

 

 

三：測試openid列二值平均分布情況

（3.1）更新資料

update record set openid = ‘1‘ where id>0 and id<=100000;update record set openid = ‘2‘ where id>100000 and id<=200000;

（3.2）openid列不使用索引

（3.2.1）查詢所有列

 

（3.2.2）  查詢tagId列

 

註：rows：顯示MYSQL估算執行查詢的行數，不是精確值，簡單且重要，數值越大越不好

分析：不使用索引時，大致掃描193958行，查詢所有列查詢時間為0.230s，查詢非索引單列為0.181s。所以，盡量不要查詢不需要的列。

 

（3.3）openid列使用建表時的索引

 

分析：openid列使用索引後，大致掃描101132行，查詢時間0.342s，相對於不使用索引，雖然掃描的行數變少了，但是查詢時間大致增加了三分之一。因為先要在BTree樹中尋找，然後再回表查詢，導致查詢時間不減反增了。所以平時我們如果在性別列等二值列建立索引，是完全沒有效果的。

 

四：建索引總結

（1）經測試，在上述20萬資料情況下，如果openid列4值平均分布的情況下，使用索引（全列查詢0.175s）和不使用索引（全列查詢0.178s）的時間大致相當。但索引還有額外記憶體等消耗，如果索引對查詢效能改善不大，在該列建立索引作用不大。

（2）建索引的情況下，根據索引查詢出的資料越多，查詢時間越長。在資料分布不均，某些索引查詢條件下，查出的資料比較多時需要注意。

（3）在區分性較高的列上建索引是比較好的選擇。

 

MySql系列一：建索引