关于 sql 优化技巧，大家可能见过 N 个版本，尤其容易博得初中级程序员的眼球。倘若没有一点分析实践能力，直接将其拿来当作圣经记在心中并实践于工作中，那你极有可能被掉坑。轻则代码运行转圈圈无响应，重则导致项目瘫痪造成经济损失。 废话不多说，直接上图。 上面这条技巧粗略看一眼好像也没有什么问题。可事实是这样的吗？ 结论当然是否定的。且看实例分析：
CREATETABLE`t_auxiliary_info`( `id`int(11)unsignedNOTNULLAUTO_INCREMENT, `ac_id`tinyint(3)unsignedNOTNULLCOMMENT'分类ID', `name`varchar(250)NOTNULLDEFAULT''COMMENT'名称', `number`smallint(6)unsignedNOTNULLDEFAULT'1'COMMENT'编号', `attr`varchar(500)NOTNULLDEFAULT''COMMENT'属性', `fdbid`int(10)unsignedNOTNULLCOMMENT'用户ID', `status`tinyint(1)unsignedNOTNULLDEFAULT'1'COMMENT'状态:1有效,0无效', `stock_type`tinyint(1)unsignedNOTNULLDEFAULT'0'COMMENT'存货类型：1库存商品，2原材料，3周转材料', PRIMARYKEY(`id`),#请注意这里的索引 KEY`uniq_cid_acid`(`fdbid`,`ac_id`) )ENGINE=InnoDBAUTO_INCREMENT=645101DEFAULTCHARSET=utf8ROW_FORMAT=DYNAMIC 上面是一张普通的业务表，仔细看表中设置的索引： PRIMARYKEY(`id`),#主键索引 KEY`uniq_cid_acid`(`fdbid`,`ac_id`)#联合索引 再使用上述的 in 或 not in 来实践以下，通过 explain 执行计划工具看看实际效果。（在这里为了公平起见，我不使用主键 id，且 in 操作中的数据不是连续的。）
select* fromt_auxiliary_info wherefdbidin('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* fromt_auxiliary_info wherefdbidnotin(1000,1500,1234,5155,6789,3423,5368,245645); 真相在这里： not in确实会全表扫描。
|
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
