Not In的主要问题是由于对Null值的处理问题所导致，那么对Null值的处理究竟为什么会导致性能问题？让我们来看图5的示例。图5中，我们使用了Adventurework示例数据库，并为了演示目的将SalesOrderDetail表的ProductId的定义由Not Null改为Null，此时我们进行一个简单的Not In查询。如图5所示。
图5.Not In的执行计划
在图5中，我们看到一个Row Count Spool操作符，该操作符用于确认ProductId列中是否有Null值（过程是对比总行数和非Null行数，不想等则为有Null值，虽然我们知道该列中没有Null值，但由于列定义是允许Null的，因此SQL Server必须进行额外的确认），而该操作符占用了接近一半的查询成本。因此我们对比Not Exists，如图6所示。
图6.Not In Vs Not Exists
由图6可以看出，Not In的执行成本几乎是Not Exists的3倍，仅仅是由于SQL Server需要确认允许Null列中是否存在Null。根据图3中Not In的等价形式，我们完全可以将Not In转换为等价的Not Exist形式，如图7所示。
图7.Not In转换为Not Exists
我们来对比图7和其等价Not In查询的成本，如图8所示。
图8.成本上完全等价
因此我们可以看到Not In需要额外的步骤处理Null值，上述情况是仅仅在SalesOrderDetail表中的ProductId列定义为允许Null，如果我们将SalesOrderHeader的SalesOrderID列也定义为允许Null时，会发现SQL Server还需要额外的成本确认该列上是否有Null值。如图9所示。
图9.SQL Server通过加入Left Anti Semi Join操作符解决列允许Null的问题
此时Not In对应的等价Not Exist形式变为如代码清单1所示。
SELECT *FROM Sales.SalesOrderHeader aWHERE NOT EXISTS ( SELECT *FROM Sales.SalesOrderDetail bWHERE a.SalesOrderID = b.ProductID )AND NOT EXISTS ( ( SELECT *FROM Sales.SalesOrderDetail bWHERE b.ProductID IS NULL) )AND NOT EXISTS ( SELECT 1FROM ( SELECT *FROM Sales.SalesOrderHeader) AS cWHERE c.SalesOrderID IS NULL )
代码清单1.当连接列两列定义都允许Null时，Not In等价的Not Exists形式
此时我们简单对比Not In和Not Exists的IO情况，如图10所示。
图10.Not In吃掉很高的IO