我遇到了一个奇怪的性能问题。我有一个基于CTE的观点。这是我几年前写的一个观点，它一直在运行，没有任何问题。突然，4天前，运行了1-2分钟的查询，运行了几个小时后，我们发现了长时间运行的查询并将其停止
CTE生成一个带有时间戳的代理执行的事务列表。然后，我从CTE中选择，使用后续事务的时间戳返回CTE，以确定代理在每个事务上花费的时间长度。
WITH [CTE_TABLE] (COLUMNS) AS
(
SELECT [INDEXED COLUMNS]
,[WINDOWED FUNCTION] AS ROWNUM
FROM [DB_TABLE]
WHERE [EMPLOYEE_ID] = 111213
)
SELECT [T1].[EMPLOYEE_ID]
,[T1].[TRANSACTION_NAME]
,[T1].[TIMESTAMP] AS [START_TIME]
,[T2].[TIMESTAMP] AS [END_TIME]
FROM [CTE_TABLE] [T1]
LEFT OUTER JOIN [CTE_TABLE] [T2] ON
(
[T1].[EMPLOYEE_ID] = [T2].[EMPLOYEE_ID]
AND [T1].[ROWNUM] = [T2].[ROWNUM] + 1
)
在测试中，我筛选特定的代理。如果它运行CTE的内部，它会在不到一秒钟的时间内产生500条记录。(如果不对单个代理进行筛选，它会在14秒内生成95K条记录。这是正常的运行时间段。)如果我用简单的SELECT*FROM[CTE_TABLE]运行CTE，它也会在不到一秒钟的时间内运行。当我使用INNER JOIN运行它时，同样，它在不到一秒钟的时间内运行。最后，当我将它作为LEFT OUTER JOIN运行时，仅单个代理的500条记录就需要一分半钟的时间。我需要LEFT OUTER JOIN，因为当天的最终记录是代理从系统注销，而且它从来没有要加入的记录。
我从中提取的表的大小超过22GB，有5亿行。从该表中选择一天的记录需要14秒，或者一个代理只需要不到一秒钟，所以我不认为性能瓶颈来自源表。瓶颈发生在返回CTE的LEFT OUTER JOIN中，但我一直使用LEFT OUTER JOIN。同样，非常奇怪的是，这是4天前才开始的。我已经检查了服务器上的空间，有足够的空间。CPU峰值约为25%，并一直保持在那里，直到查询结束运行，无论是自行运行，还是由管理员停止运行。
我希望有人能对造成这种情况的原因有一些想法。它似乎是不知从哪里冒出来的。
同样，非常奇怪的是，这在 4天前才开始
我建议更新相关表的统计信息，并尝试重建索引
瓶颈出现在返回CTE 的LEFT OUTER JOIN中
CTE将没有任何统计数据，我建议将CTE材料化为Temp表，看看这是否有助于