交叉應用（select top 1）比row_number（）慢得多

Question

使用AdventureWorks，下面列出的是對For each Product get any 1 row of its associated SalesOrderDetail的查詢。

使用cross apply需要14000ms。等效的row_number版本只需要70ms（快200倍）。

cross apply也比所有產品和SalesOrderDetails的簡單inner join慢，它返回121317行（當限制TOP 1時爲266行）。

我更喜歡這種查詢的cross apply語法，因爲它比row_number版本更乾淨。但顯然cross apply版本正在使用非常低效的執行計劃，並且太慢而無法使用。

在我看來，查詢不按預期工作。運行這個簡單的查詢不需要14秒鐘。我在其他情況下使用了cross apply，從未遇到任何緩慢的事情。我的問題是：這個特殊的查詢是如何混淆查詢優化器？是否有任何查詢提示可用於幫助其使用最佳執行計劃？正如@pacreely所建議的，我爲每個查詢添加了統計信息。

--CROSS APPLY ~14000ms 
SELECT P.ProductID 
     ,P.Name 
     ,P.ProductNumber 
     ,P.Color 
     ,SOD.SalesOrderID 
     ,SOD.UnitPrice 
     ,SOD.UnitPriceDiscount 
     ,SOD.LineTotal 
FROM Production.Product P 
     CROSS APPLY (SELECT TOP 1 
           * 
         FROM  Sales.SalesOrderDetail S 
         WHERE  S.ProductID = P.ProductID) SOD; 

--ROW_NUMBER ~70ms 
SELECT * 
FROM (SELECT P.ProductID 
        ,P.Name 
        ,P.ProductNumber 
        ,P.Color 
        ,SOD.SalesOrderID 
        ,SOD.UnitPrice 
        ,SOD.UnitPriceDiscount 
        ,SOD.LineTotal 
        ,ROW_NUMBER() OVER (PARTITION BY P.ProductID ORDER BY P.ProductID) RowNum 
      FROM  Production.Product P 
        INNER JOIN Sales.SalesOrderDetail SOD ON SOD.ProductID = P.ProductID) X 
WHERE X.RowNum = 1; 

--Simple INNER JOIN ~400ms (121317 rows) 
SELECT P.ProductID 
     ,P.Name 
     ,P.ProductNumber 
     ,P.Color 
     ,SOD.SalesOrderID 
     ,SOD.UnitPrice 
     ,SOD.UnitPriceDiscount 
     ,SOD.LineTotal 
FROM Production.Product P 
     INNER JOIN Sales.SalesOrderDetail SOD ON SOD.ProductID = P.ProductID; 

也許與此相關的問題，cross apply沒有SalesOrderDetail.LineTotal是速度快10倍。

--CROSS APPLY (Without LineTotal) ~1200ms 
SELECT P.ProductID 
     ,P.Name 
     ,P.ProductNumber 
     ,P.Color 
     ,SOD.SalesOrderID 
     ,SOD.SalesOrderDetailID 
     ,SOD.CarrierTrackingNumber 
     ,SOD.OrderQty 
     ,SOD.ProductID 
     ,SOD.SpecialOfferID 
     ,SOD.UnitPrice 
     ,SOD.UnitPriceDiscount 
     ,SOD.rowguid 
     ,SOD.ModifiedDate 
FROM Production.Product P 
     CROSS APPLY (SELECT TOP 1 
           * 
         FROM  Sales.SalesOrderDetail S 
         WHERE  S.ProductID = P.ProductID) SOD; 

Execution plans

跨應用統計

SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 
SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

(266 row(s) affected) 
Table 'SalesOrderDetail'. Scan count 1, logical reads 363114, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'Product'. Scan count 1, logical reads 15, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

(1 row(s) affected) 

SQL Server Execution Times: 
    CPU time = 15688 ms, elapsed time = 16397 ms. 
SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

ROW_NUMBER統計：

SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 
SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

(266 row(s) affected) 
Table 'Product'. Scan count 9, logical reads 40, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'SalesOrderDetail'. Scan count 9, logical reads 1371, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

(1 row(s) affected) 

SQL Server Execution Times: 
    CPU time = 360 ms, elapsed time = 266 ms. 
SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

Answer 1

感謝您的所有建議。正如我暗示的那樣，我檢查並發現LineTotal實際上是一個計算列。所以它是有道理的，它將會減慢每一行的速度，因爲每一行都會重複計算。但是，即使沒有LineTotal，如上所示，它仍然太慢。然後導致我刪除除cross apply條款中的Id之外的所有列。最後，我添加了一個內部聯接來檢索所有需要的列。這將cross apply查詢作爲row_number查詢

SELECT P.ProductID 
     ,P.Name 
     ,P.ProductNumber 
     ,P.Color 
     ,SOD.SalesOrderID 
     ,SOD.UnitPrice 
     ,SOD.UnitPriceDiscount 
     ,SOD.LineTotal 
FROM Production.Product P 
     CROSS APPLY (SELECT TOP 1 
           S.SalesOrderDetailID 
         FROM  Sales.SalesOrderDetail S 
         WHERE  S.ProductID = P.ProductID) SODID 
     INNER JOIN Sales.SalesOrderDetail SOD ON SOD.SalesOrderDetailID = SODID.SalesOrderDetailID 

Answer 2

試圖讓四個語句的執行計劃一起作爲一個批次和看看報告的「百分比e相對於批次「對於每一個類似於你的時間。這可能是你有一些過時的統計數據。

Answer 3

與

SET STATISTICS IO ON 

運行查詢您會看到CROSS APPLY可能產生更多的讀取。 這是因爲您正在執行Sales.SalesOrderDetails表的多個/重複讀取

此外，不要假設RowNumber查詢是「更快」。 SQL已經決定它是一個昂貴的查詢，所以它已經並行並且使用了多個處理器「快速但是資源昂貴」。 與

SET STATISTICS TIME ON 

看看CPU時間，而不是過去的時間運行查詢，這會給你查詢的真實速度。

當您查看每個查詢的執行計劃時，請檢查Select組件的詳細信息。有一個查詢的總成本度量。如果成本大於服務器的最大並行度（默認值爲5，除非您的DBA更改了它），那麼sql將生成並行查詢計劃以提高已用時間。