Question

PRINT＆＃39; ------------------------------- TEMP ---------- ----------------------------------＆＃39;

SELECT DISTINCT ZipCode 
INTO #ZipCodes
FROM tb_PROD_ADDRESS_RANGE par
WHERE par.DeletedFlag = 0

SELECT
      FileStatusId          
     ,FileStatusReasonId    
    FROM tb_RECORD_IMPORT as import
    LEFT JOIN #ZipCodes AS pr ON import.ZIP_CODE = pr.ZipCode

PRINT '-------------------------------CTE--------------------------------------------'

;WITH ZipCodes AS (
    SELECT DISTINCT ZipCode 
    FROM tb_PROD_ADDRESS_RANGE par
    WHERE par.DeletedFlag = 0
)
SELECT 
        FileStatusId        
        ,FileStatusReasonId 
    FROM tb_RECORD_IMPORT as import
    LEFT JOIN ZipCodes AS pr ON import.ZIP_CODE = pr.ZipCode

ABOVE是实际程序中的实际sql。

我有一个在所有环境中都落后的过程，并且它在CTE上滞后，并且使用临时表可以更好地运行该过程。

它是一个更大的触发器的一部分，但它在这个位置上滞后，无论它在何处被移动。

我不明白为什么会出现这种情况。目标表不大，CTE相当于910条记录。

当我看到这块代码的影响时，CTE似乎应该表现得更好。但是当作为更大的包装/程序的一部分运行时，它就是事物在停滞不前的地方。

我不认为问题是CTE，而是内部胆量中的其他问题。我有人建议参数嗅探，但没有参数！

统计数据是最新的。是否存在SSIS挂在内存上的问题或者会对此产生影响的问题？

*********************************** EPILOGUE *********** ********************************************** 工作接管了，因为这个问题已经解决了。更大的火灾正在燃烧，有一个延迟...

在得到关于分享执行计划的xml的最佳方法的答案之前，我已经按照评论中的好人推荐的方式生成了执行计划...

虽然我仍然感到困惑，为什么差异与下面的测试相反，但这就是为什么在使用环境中测试sql代码很重要的原因。 ..

临时表解决方案的执行计划是一个典型的计划，其中包含一些搜索和并行化。许多物品，不确定一切意味着什么。甚至还有建议的索引。

然而， CTE解决方案计划非常容易掌握。这是一个动作，100％。全表扫描。

我怀疑真正的问题甚至不是整个表扫描本身，而是这个代码块夹在许多其他代码中，这些代码占用资源。

-------------------------------TEMP--------------------------------------------
 SQL Server Execution Times:

   CPU time = 0 ms,  elapsed time = 0 ms.
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 'tb_PROD_ADDRESS_RANGE'. Scan count 1, logical reads 4215, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

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

(910 row(s) affected)

(206949 row(s) affected)
Table '#ZipCodes___________________________________________________________________________________________________________00000000017C'. Scan count 17, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'tb_RECORD_IMPORT'. Scan count 17, logical reads 22157, 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.

 SQL Server Execution Times:
   CPU time = 1822 ms,  elapsed time = 1378 ms.
-------------------------------CTE--------------------------------------------

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

(206949 row(s) affected)
Table 'tb_RECORD_IMPORT'. Scan count 1, logical reads 20027, physical reads 0, read-ahead reads 202, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

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

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

Answer 1

*********************************** EPILOGUE *********** **********************************************工作接手了，因为这个问题已得到修复＆＃39;更大的火灾正在燃烧，有一个延迟...

在得到关于分享执行计划的xml的最佳方法的答案之前，我已经按照评论中的好人推荐的方式生成了执行计划...

虽然我仍然感到困惑，为什么差异与下面的测试相反，但这就是为什么在使用环境中测试sql代码很重要的原因。 ..

临时表解决方案的执行计划是一个典型的计划，其中包含一些搜索和并行化。许多物品，不确定一切意味着什么。甚至还有建议的索引。

然而，CTE解决方案计划很容易掌握。这是一个动作，100％。全表扫描。

我怀疑真正的问题甚至不是整个表扫描本身，而是这个代码块夹在许多其他代码中，这些代码占用资源。

Answer 2

CTE的执行速度明显变慢，最好始终使用临时表。有关这方面的更多信息，请参阅之前的问题

Which are more performant, CTE or temporary tables?

过程在微小的CTE上停滞

2 个答案: