mysql优化技巧有何误区

本文主要给大家介绍mysql优化技巧有何误区，文章内容都是笔者用心摘选和编辑的，具有一定的针对性，对大家的参考意义还是比较大的，下面跟笔者一起了解下mysql优化技巧有何误区吧。        

        上面这条技巧粗略看一眼好像也没有什么问题。可事实是这样的吗？

        结论当然是否定的。且看实例分析：        

CREATE TABLE `t_auxiliary_info` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `ac_id` tinyint(3) unsigned NOT NULL COMMENT &＃39;分类ID&＃39;,
  `name` varchar(250) NOT NULL DEFAULT &＃39;&＃39; COMMENT &＃39;名称&＃39;,
  `number` smallint(6) unsigned NOT NULL DEFAULT &＃39;1&＃39; COMMENT &＃39;编号&＃39;,
  `attr` varchar(500) NOT NULL DEFAULT &＃39;&＃39; COMMENT &＃39;属性&＃39;,
  `fdbid` int(10) unsigned NOT NULL COMMENT &＃39;用户ID&＃39;,
  `status` tinyint(1) unsigned NOT NULL DEFAULT &＃39;1&＃39; COMMENT &＃39;状态:1有效,0无效&＃39;,
  `stock_type` tinyint(1) unsigned NOT NULL DEFAULT &＃39;0&＃39; COMMENT &＃39;存货类型：1库存商品，2原材料，3周转材料&＃39;,
  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(&＃39;1000&＃39;,&＃39;1500&＃39;,&＃39;1234&＃39;,&＃39;5155&＃39;,&＃39;6789&＃39;,&＃39;3423&＃39;,&＃39;5368&＃39;,&＃39;245645&＃39;);        

在上面的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优化技巧有何误区，很多读者朋友肯定多少有一定的了解，如需获取更多的行业知识信息 ，可以持续关注我们的行业资讯栏目的。