SQL 2005 CTE与临时表性能(当用于其他表的联接时)

你问了一个复杂的问题,所以你得到了一个复杂的答案:这要看情况(我讨厌这种反应)。

但是,说真的,这与优化器如何选择数据计划有关(您已经知道);临时表或变量类似于永久结构,因为执行计划将首先执行与填充该结构相关的操作,然后在后续操作中使用该结构。CTE不是临时表;在后续操作使用CTE之前,不会计算CTE的使用,因此使用会影响计划的优化方式。

CTE的实施是为了可重用性和维护问题,不一定是为了性能;然而,在许多情况下(如递归),它们的性能将优于传统的编码方法。

CTE 只是查询的别名。

它可能(也可能不)在每次使用时都会重新运行。

CTE 物质化 SQL Server /*+ MATERIALIZE */ ),你必须做这样肮脏的把戏:

• Generating XML in subqueries

CTE HASH JOIN , MERGE JOIN

在这些场景中,哈希表将直接从 CTE ,将结果拉入临时表并再次读取临时表。

我发现重复的CTE通常不会得到性能改进。

我经常使用内联TVF(可能包含CTE)代替CTE,它允许正确的重复使用,并且不比我的SP中的CTE更好或更差。

此外,我还发现,如果第一步改变了统计信息,那么第二步的执行计划总是不准确的,因为它是在任何步骤运行之前进行评估的,那么执行计划可能是不好的。

我试着用大表中的简单选择过滤器创建CTE 然后3次子查询它。

之后,对临时表执行相同的操作。

因此,临时表更适合该解决方案。

我不认为CTE只使用选定的查询生成临时表,而是3次将select生成一个大表。