sql语句,实践证明了某种情况下not in的效率高于not exists

只要百度not in和not exists,清一色的not exists的效率优于not in,毕竟not exists只是去强调是否返回结果集,只是一个bool值,而not in是返回一个结果集,是由大量大量数据构成的。所以一开始我在做的时候写的是not in,然后前辈告诉我效率太低,改成了not exists,结果查询速度特别慢。为什么呢?首先来看看sql语句,本身sql语句特别长,只写出where条件中的not in和not exists筛选部分语句。

not in: where substr(表A.字段A,1,9) not in (select substr(字段B,1,9) from 表B) and 表A.字段C not in (select 字段D from 表C)

not exists:where not exists (select 1 from 表B where substr(表B.字段B,1,9) = substr(表A.字段A,1,9) and not exists (select 1 from 表C where 表C.字段D = 表A.字段C)

主表是表A,大概也就不超过10万的数据量吧,然后前面表A先做过一次inner join和两次left join,inner join排除了表A中将近六分之五的数据,两次left join中一次是替换掉表A中的某个字段的值,另一次多取一次值。这些处理都花极其少的时间。然后现在这么做远远不够,表A还要根据另外两张表中的数据来进行再次过滤。这个行为就是通过两个not in来完成的。一开始借鉴了前辈的提议,用了not exists,毕竟返回一个bool值是大量的节省时间,然后实际结果下来却花了整整3秒多,这对于一个用户来是完完全全不能接受的。为什么原因呢?最后推导出原因肯定是在前一句not exists中的两个substr。表B中大概只有5000不到的数据,然而表A里面却有几万条数据,用表B中的每个值和表A中的每个值都要进行一次比较处理,那会是多么一个庞大的处理!!尽管not exists只是返回一个bool值,但是却忽略了里面select语句中where的处理量,而且还要进行一次substr处理。一开始没有想到再去用not in处理,先想到的用的是视图,因为想去除掉一次substr处理,提前把表A中的数据处理好放到视图里,然后再进行处理。结果更加令人意外,视图更加慢,而且还取不到正确结果。这部分的原因我猜应该是表A里面有两个主键,而我做视图的过程中只取了其中一个主键,但是这个取出的这个主键是受后面那个主键约束的,创建了垃圾数据比较多的视图。(其实我本来也不太会视图,还是前辈教的= =。。)我抱着破罐子破摔的想法把not exists换成了not in,然后奇迹出现了,取完整个数据0.1秒一下级别的,反正一眨眼的时间。。完美的符合了系统不管什么处理都不能超过3秒的要求。。

为什么not in在这种情况下效率远远高于not exists呢?按我一介菜鸟的理解,not exists里面的where处理拖慢了整个速度,况且这次处理本来就是想要返回结果集,况且在这之前已经拿了表A.字段A,最终正确的数据是根据这个字段A来获取的,只要拿出不与从其它两张表不匹配的数据即可,就相当于整理衣柜,把没用的衣服拿出来这一个过程而已。而且字段A,B,C,D都是各个表的主键,不存在null值这种概念,没有必要进行额外的判断。所以最后not in的速度比not exists整整快了3秒有余。

数据库是DB2(不要吐槽,日企就是这么喜欢IBM,顶层终于考虑要换oracle。。。)

一介菜鸟,写的错误的地方,欢迎大神提意见,谢谢~~

 

转载于:https://www.cnblogs.com/dachuyin/p/6505591.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值