T-SQL查询为何慎用IN和NOT IN详解
前言
今天突然想到之前在书上看到的一个例子,竟然想不起来了.
于是翻书找出来,测试一下.
in和exists差异开始测试吧,现在测试使用in、not in 可能带来的“错误”。之所以错误,是因为我们总是以自然语言去理解sql,却忽略了数学中的逻辑语法。不废话了,测试看看吧!
【测试一:in子查询】
说明:
两个查询都执行没有出错,但是第二个tsql的子查询写错了。子查询(select oid from son)实际单独执行会出错,因为表son不存在字段oid,但是在这里系统不会提示错误。而且father表有4行数据,所有子查询扫描了4次son表,但是第二个查询中,实际也只扫描了1次son表,也就是son表没有用到。
即使这样写也 不会出错: select*fromfatherwherefidin(selectoid)
这个查询的意思是,表father中每行的fid与oid比较,相同则返回值。
实际查询是这样的: select * from father where fid = oid
测试一中,fid in(select fid from son)子查询中包含null值,所以 fid in(null)返回的是一个未知值。但是在刷选器中,false和unknown的处理方式类似。因此第一个子查询返回了正确的结果集。
【测试二:not in子查询】
说明:
查看select fid from son,子查询中有空值null,子查询中的值为(2,3,null),谓词fid in(2,3,null)永远不会返回false,只反会true或unknown,所以谓词fidnot in(2,3,null)只返回not true 或not unknown,结果都不会是true。所以当子查询存在null时,not in和not exists 在逻辑上是不等价的。
总结:
in 或 not in在sql语句中经常用到,尤其当子查询中有空值的时候,要谨慎考虑。因为即使写了“正确”的脚本,但是返回结果却不正确,也不出错。在不是很理解的情况下,最好使用 exists和 not exists来替换。而且exists查询更快一些,因为只要在子查询找到第一个符合的值就不继续往下找了,所以能用exists就用吧。
到此这篇关于t-sql查询为何慎用 in和not in详解的文章就介绍到这了,更多相关t-sql查询慎用 in和not in内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!
上一篇: 秃发皇后是谁?她是怎么死的
推荐阅读
-
关于Django ForeignKey 反向查询中filter和_set的效率对比详解
-
T-SQL查询为何慎用IN和NOT IN详解
-
T-SQL查询为何慎用IN和NOT IN详解
-
关于Sequelize连接查询时inlude中model和association的区别详解
-
Yii基于数组和对象的Model查询技巧实例详解
-
MongoDB模糊查询操作案例详解(类关系型数据库的 like 和 not like)
-
mysql查询每小时数据和上小时数据的差值实现思路详解
-
php慢查询日志和错误日志使用详解
-
mysql查询时offset过大影响性能的原因和优化详解
-
css3媒体查询中device-width和width的区别详解