一個mysql優化技巧的誤區

        關於sql優化技巧，大家可能見過N個版本，尤其容易博得初中級程序員的眼球。倘若沒有一點分析實踐能力，直接將其拿來當作聖經記在心中並實踐於工作中，那你極有可能被掉坑。輕則代碼運行轉圈圈無響應，重則導致項目癱瘓造成經濟損失。

        廢話不多說，直接上圖。

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

        

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

        

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確實會全表掃描。