mysql優(yōu)化技巧有何誤區(qū)

本文主要給大家介紹mysql優(yōu)化技巧有何誤區(qū)，文章內(nèi)容都是筆者用心摘選和編輯的，具有一定的針對性，對大家的參考意義還是比較大的，下面跟筆者一起了解下mysql優(yōu)化技巧有何誤區(qū)吧。        

        上面這條技巧粗略看一眼好像也沒有什么問題?？墒聦?shí)是這樣的嗎？

        結(jié)論當(dāng)然是否定的。且看實(shí)例分析：        

CREATE TABLE `t_auxiliary_info` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `ac_id` tinyint(3) unsigned NOT NULL COMMENT '分類ID',
  `name` varchar(250) NOT NULL DEFAULT '' COMMENT '名稱',
  `number` smallint(6) unsigned NOT NULL DEFAULT '1' COMMENT '編號',
  `attr` varchar(500) NOT NULL DEFAULT '' COMMENT '屬性',
  `fdbid` int(10) unsigned NOT NULL COMMENT '用戶ID',
  `status` tinyint(1) unsigned NOT NULL DEFAULT '1' COMMENT '狀態(tài):1有效,0無效',
  `stock_type` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '存貨類型：1庫存商品，2原材料，3周轉(zhuǎn)材料',
  PRIMARY KEY (`id`),#請注意這里的索引
  KEY `uniq_cid_acid` (`fdbid`,`ac_id`)
) ENGINE=InnoDB AUTO_INCREMENT=645101 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC

    上面是一張普通的業(yè)務(wù)表，仔細(xì)看表中設(shè)置的索引：

  PRIMARY KEY (`id`),#主鍵索引
  KEY `uniq_cid_acid` (`fdbid`,`ac_id`)#聯(lián)合索引        

        再使用上述的in 或not in 來實(shí)踐以下，通過explain執(zhí)行計(jì)劃工具看看實(shí)際效果。（在這里為了公平起見，我不使用主鍵id，且in操作中的數(shù)據(jù)不是連續(xù)的。）        

select * 
from t_auxiliary_info 
where fdbid in('1000','1500','1234','5155','6789','3423','5368','245645');        

在上面的sql中，我們使用包含在聯(lián)合索引`uniq_cid_acid`中的字段 `fdbid`作為搜索條件 

       見證奇跡的時(shí)刻到了。

        通過執(zhí)行計(jì)劃， 我們可以清晰的看到這條sql的檢索類型為簡單簡單檢索，屬于范圍查詢，且已經(jīng)使用到了索引  uniq_cid_acid，且沒有全表掃描（掃描行數(shù)為2804，而本表中數(shù)據(jù)條數(shù)為645101）。

        由此可以得出結(jié)論：不是所有sql中的in查詢會(huì)全表掃描。這里推翻了in會(huì)導(dǎo)致全表掃描的結(jié)論。

        那么在什么情況下，使用in操作一樣可以使用到索引，不會(huì)全表掃描呢？

       答：  in的字段必須是帶有索引的字段。

       ps：  in(...) 中的數(shù)據(jù)最好加上引號,即使字段類型是數(shù)字。

        在 看看not in       

select * 
from t_auxiliary_info 
where fdbid not in(1000,1500,1234,5155,6789,3423,5368,245645);

        真相在這里：

not in確實(shí)會(huì)全表掃描。

看完以上關(guān)于mysql優(yōu)化技巧有何誤區(qū)，很多讀者朋友肯定多少有一定的了解，如需獲取更多的行業(yè)知識信息 ，可以持續(xù)關(guān)注我們的行業(yè)資訊欄目的。