在SQL Server中Not In子查詢性能分析

Not In的主要問題是由于對Null值的處理問題所導致，那么對Null值的處理究竟為什么會導致性能問題？讓我們來看圖5的示例。圖5中，我們使用了Adventurework示例數據庫，并為了演示目的將SalesOrderDetail表的ProductId的定義由Not Null改為Null，此時我們進行一個簡單的Not In查詢。如圖5所示。

圖5.Not In的執(zhí)行計劃

在圖5中，我們看到一個Row Count Spool操作符，該操作符用于確認ProductId列中是否有Null值（過程是對比總行數和非Null行數，不想等則為有Null值，雖然我們知道該列中沒有Null值，但由于列定義是允許Null的，因此SQL Server必須進行額外的確認），而該操作符占用了接近一半的查詢成本。因此我們對比Not Exists，如圖6所示。

圖6.Not In Vs Not Exists

由圖6可以看出，Not In的執(zhí)行成本幾乎是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時，會發(fā)現SQL Server還需要額外的成本確認該列上是否有Null值。如圖9所示。

圖9.SQL Server通過加入Left Anti Semi Join操作符解決列允許Null的問題

此時Not In對應的等價Not Exist形式變?yōu)槿绱�碼清單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