小CTE上的过程停止

Question

PRINT'------------------------------- TEMP -------- ------------------------------------'

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，过程运行在使用临时表更好。

这是一个较大的PROC的一部分，但它无论滞后在这一点上，在那里它可在此过程中移动。

我不明白的是为什么会这样。目标表不是那么大，CTE等于910个记录。

当我看到这个区块的代码的影响，CTE似乎应该有更好的表现。但是当作为更大包装/程序的一部分运行时，这是一个静止不动的地方。

我不认为这个问题是CTE但一些内部胆量人。我有人建议参数嗅探，但没有参数！

统计信息是最新的。 SSIS挂在内存上还是会有问题影响到这一点？

*********************************** EPILOGUE ********** *********************************** 工作花了并且由于这个问题已被“固定”并且更大的火灾正在燃烧，所以延迟了......

在得到关于共享执行计划的最佳方法的答案之前，我已经尽可能根据评论中好人推荐的执行计划生成执行计划...

并且得到了答案，尽管我仍然困惑为什么差异与下面的测试相反，但这就是为什么测试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

****************************** *****结语******************************************** *************工作接管了，由于这个问题已经“解决”了，而更大的火灾正在燃烧，因此出现了延误......

之前获取有关最佳方法的答案，分享了执行计划的XML，我已经尽可能所推荐的优秀的人在评论中生成执行计划得到...

和有虽然我仍然不明白为什么差异与以下测试相反，但这就是为什么在正在使用的上下文中测试sql代码非常重要...

临时表解决方案的执行计划是一些寻求和并行化的典型计划正在发生。许多物体，不知道什么都意味着什么。甚至有一个建议的指数。

但是，CTE解决方案计划很容易掌握。这是一种行为，100％。全表扫描。

我怀疑真正的问题不在于它本身的全表扫描，而是这块代码夹在许多其他捆绑资源的代码中。

Answer 2

CTE的执行速度明显较慢，最好总是使用临时表。 更多这方面的信息，请参阅前面问

Which are more performant, CTE or temporary tables?