mysql優化技巧有何誤區

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

        上面這條技巧粗略看一眼好像也沒有什么問題。可事實是這樣的嗎？

        結論當然是否定的。且看實例分析：        

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 '狀態:1有效,0無效',
  `stock_type` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '存貨類型：1庫存商品，2原材料，3周轉材料',
  PRIMARY KEY (`id`),#請注意這里的索引
  KEY `uniq_cid_acid` (`fdbid`,`ac_id`)
) ENGINE=InnoDB AUTO_INCREMENT=645101 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC

    上面是一張普通的業務表，仔細看表中設置的索引：

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

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

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

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

       見證奇跡的時刻到了。

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

        由此可以得出結論：不是所有sql中的in查詢會全表掃描。這里推翻了in會導致全表掃描的結論。

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

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

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

        在 看看not in       

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

        真相在這里：

not in確實會全表掃描。

看完以上關于mysql優化技巧有何誤區，很多讀者朋友肯定多少有一定的了解，如需獲取更多的行業知識信息 ，可以持續關注我們的行業資訊欄目的。