SQL中NOT IN一个致命的问题

Myth丶恋晨 2022-09-11 05:21 139阅读 0赞

今天项目中遇到一个问题导致系统即将瘫痪，排查的好久最后发现是SQL中NOT IN写法问题导致的，所以在这里总结一下。首先，EXISTS与IN和用法想必大家都非常清楚，百度一下，网上也有很多介绍，一般情况下EXISTS与IN的使用效率的问题，通常情况下采用EXISTS要比IN效率高，因为IN不走索引，但要看实际情况具体使用：IN适合于外表大而内表小的情况，而EXISTS适合于外表小而内表大的情况。但有一种情况，NOT EXISTS和NOT IN的SQL查询中子查询包含NULL，这样的话两者查询结果截然不同：

首先我们先创建两个表：

--表t1
    create table t1 (id number);
    insert into t1 values(1);
    insert into t1 values(2);
    insert into t1 values(3);
    insert into t1 values(4);
    
    --表t2
    create table t2 (id number);
    insert into t2 values(3);
    insert into t2 values(4);
    insert into t2 values(5);
    insert into t2 values(6);
    insert into t2 values(null);

表t1显示结果如下：

![20210913115242676.png][]

表t2显示结果如下：

![20210913115324954.png][]

接下来重点来了，我们来看以下两种写法的查询结果：

![20210913115623742.png][]

![202109131156382.png][]

看到这里你有什么想法？从上面的查询结果中可以看出两个结果差异很大，not exists把id=1和2的值都查出来了，而not in查出来的结果为空。项目中就是因为采用的第二种写法导致无查询结果，从而导致HIS系统收不到费。所以，不管是从效率考虑，还是从是否包含特殊情况考虑，都建议使用exists写法。

不过，上面图2中not in写法你也可以改成下面的写法，效果也是一样的：

![20210913120728306.png][]

以上是项目中遇到的实际问题，关于SQL写法以及编写SQL脚本的严谨性，一定要慎之又慎，望警惕！

[20210913115242676.png]: /images/20220828/b8f7589f4e674555a359d5b80babfdc7.png
[20210913115324954.png]: /images/20220828/32c68e273ca64bdea1dc23048a2c13a8.png
[20210913115623742.png]: /images/20220828/1dbfd069adda484f8ea12d9e5eda1681.png
[202109131156382.png]: /images/20220828/80f9a9542c704bff87a5dd46c341b526.png
[20210913120728306.png]: /images/20220828/2ca8a86e228e42f6adf1c1e0e16984e5.png