前面我们学习了NOT EXISTS和NOT IN的比较，当然少不了EXISTS和IN的比较，所以本节我们来学习EXISTS和IN的比较，简短的内容，深入的理解，Always to review the basics。
我们创建表Table1并且取出前面创建BigTable表中的六条数据并插入其中，同时有一条数据重复，如下：
此时我们来进行IN查询
我们在之前讲过若是内部联接中此时会返回六条数据，因为内部联接着重强调的是JOIN后面的表，若右表有多条数据匹配上，此时则会返回多条数据，但是在IN查询中，此时只会返回五条数据，为何如此呢？
此时用IN查询时即使在子查询中有重复数据时也不会担心出问题，它会自动进行过滤处理，因为在上图中利用了Semi Join半联接中右半联接或左半联接，也就是说只返回重复的数据中的一条。那么在EXISTS中情况又是怎样呢？
此时因为没有WHERE条件，此时会返回外部查询表中所有数据，为了和上述IN查询实现等同的结果，我们需要加上WHERE条件
而EXISTS相对于IN来说当需要比较两个或两个以上条件时，EXISTS能更好的实现而IN就没那么容易了，比如如下
好了，到了这里我们开始讲讲二者性能问题
我们直接利用前面的表来进行查询
二者都是利用默认的聚集索引扫描和哈希匹配中的右半联接且开销一致。接下来我们再来在二者查询列上创建索引
此时只是创建了索引后查询效率改善了，而且查询计划较之前只是哈希匹配中的左半联接替换成了合并联接中的内部联接，同时增加了流聚合。二者在开销上仍是一致的。在我所看其他教程中印象中一直都在说利用EXISTS代替IN，其EXISTS查询性能高于IN，而且事实却是开销一致，难道是100万数据太小，还是场景不够，还是语句不够复杂么。都在说看使用场景，那么到底是在什么场景下EXISTS比IN性能好呢，对此有更深入了解的你们，希望在评论中得到最实际的回答。而我认为觉得用EXISTS的话，只是EXISTS比IN更加灵活而已，而且不会出现意外的结果。下面我们继续往下看。
我们接下来看看用IN会出现什么意外的情况，我们首先创建测试表，并插入数据如下：
插入测试数据
table1和table2中的数据分别如下：
我们来对比EXISTS和IN查询，如下：
此时二者返回的结果都是正确，接下来我们再来看其他情况，我们需要获取所有table1中数据没有在table2中的所有行。
此时利用EXISTS得到了正确的结果，而通过IN查询未达到我们查询的目的，原因之前也有说过IN是基于三值逻辑，此时遇到NULL则会当做UNKNOWN来处理，所以最终得到的结果集是错误的。我们继续往下探讨。
我们重新创建测试表并插入测试数据，如下：
我们首先进行如下查询：
此时结果是正确的，假如在子查询中我们将列id2写成了id1，那么情况又会是怎样的呢？
不知你是否注意到什么没有，表面是没什么问题，我们接着运行下上述子查询
单独运行查询时，结果居然出错了，到这了我们再看下创建的表的列，id1是在Table1中而非在Table2中，所以导致了这种意外的错误，如果手写错误，结果数据也有，一般是不会觉察不到，通过使用IN查询就导致了意外的出现。而如下利用EXISTS时会直接报错，而不是得到错误的结果集
当然了也有人会说根本不会犯这样低级错误，但是谁能保证呢，SQL有智能提示更加容易犯这样的错误，因为直接在子查询就会有这样的列出现，但是该列在子查询表中根本不存在。所以基于探讨的两点，利用EXISTS更加保险。到此，关于EXISTS和IN的介绍算是结束，下此结论。
EXISTS和IN性能分析结论：我们推荐使用EXISTS，而不是IN，原因不是EXISTS性能优于IN，二者性能开销是一样的，而是利用EXISTS比IN更加灵活，更加安全、保险不会出现意想不到的结果。
本节我们讲解了EXISTS和IN，关于其二者在性能方面还是有点疑惑，毕竟场景不够，当然最后还是推荐使用EXISTS，而原因不在于性能。我们下节讲解LEFT JOIN和NOT EXISTS，简短的内容，深入的理解，我们下节再会。