FAST_FORWARD游标何时会有一个工作表（这是否应该避免）？

Question

背景

我注意到在尝试运行总查询时，有时估计的计划只显示“获取查询”

并且实际计划显示了聚集索引扫描的重复提取

在其他场合（例如，在向查询添加TOP时），估计的计划显示填充工作表的“人口查询”阶段

实际计划显示聚集索引扫描以填充工作表，然后重复搜索该工作表。

问题

1. SQL Server在选择一种方法时使用的标准是什么？
2. 我认为第一种方法（没有额外的工作表填充步骤）更有效率，我是否正确？

（额外的问题：如果有人能够解释为什么第一个查询中的每个扫描都算作2个逻辑读取，这可能也很有启发性）

其他信息

我发现this article here解释了FAST_FORWARD游标可以使用动态计划或静态计划。在这种情况下，第一个查询似乎是使用动态计划，第二个查询是静态计划。

我还发现如果我尝试

SET @C2 = CURSOR DYNAMIC TYPE_WARNING FOR SELECT TOP ...

光标被隐式转换为keyset光标，因此很明显动态光标不支持TOP构造，也许是出于Ruben答案的原因 - 仍在寻找明确的解释此

但是我还读到动态光标比静态光标（source 1，source 2更倾向于更慢，这似乎让我感到惊讶，因为静态变量有读取源数据，复制它，然后读取副本而不是只读取源数据。 The article I referenced earlier提到动态游标使用markers。谁能解释一下这些是什么？它只是一个RID或CI键，还是不同的东西？

脚本

SET STATISTICS IO OFF

CREATE TABLE #T ( ord INT IDENTITY PRIMARY KEY, total INT, Filler char(8000))

INSERT INTO #T (total) VALUES (37),(80),(55),(31),(53)

DECLARE @running_total INT, 
    @ord INT, 
    @total INT

SET @running_total = 0
SET STATISTICS IO ON
DECLARE @C1 AS CURSOR;
SET @C1 = CURSOR FAST_FORWARD FOR SELECT ord, total FROM #T ORDER BY ord;
OPEN @C1;
PRINT 'Initial FETCH C1'
FETCH NEXT FROM @C1 INTO @ord, @total ;
WHILE @@FETCH_STATUS = 0
BEGIN
  SET @running_total = @running_total + @total
  PRINT 'FETCH C1'
  FETCH NEXT FROM @C1 INTO @ord, @total ;
END

SET @running_total = 0
SET STATISTICS IO ON
DECLARE @C2 AS CURSOR;
SET @C2 = CURSOR FAST_FORWARD FOR SELECT TOP 5 ord, total FROM #T ORDER BY ord;
OPEN @C2;
PRINT 'Initial FETCH C2'
FETCH NEXT FROM @C2 INTO @ord, @total ;
WHILE @@FETCH_STATUS = 0
BEGIN
  SET @running_total = @running_total + @total
  PRINT 'FETCH C2'
  FETCH NEXT FROM @C2 INTO @ord, @total ;
END

PRINT 'End C2'
DROP TABLE #T 

Answer 1

只是预感，但通常TOP-ORDER BY要求SQL Server以某种方式缓冲结果（索引扫描的结果或整个结果在临时结构中，或两者之间的任何内容）。

有人可能会争辩说，对于游标，即使按主键排序（如在您的示例中）也是必要的，因为当相应的SELECT确实返回5时，您不能允许TOP 5游标意外返回少于5行。行（或更糟：光标返回超过5行）。

理论上，当已经确定了游标的索引扫描范围，和插入/删除后，表上有删除或插入时，理论上会出现这种奇怪的情况。落在索引扫描的范围内，但你尚未完成提取。为了防止这种情况发生，他们可能会在这里安全地犯错。 （他们只是没有针对#temp表进行优化。）

但问题是：SQL Server是否允许FETCH FROM SELECT TOP n没有ORDER BY子句？ （没有在这里运行SQL Server实例。）可能有趣的是知道导致什么计划。

Answer 2

SQL Server在选择一种方法时使用什么标准？

这主要是基于成本的决策。引用您链接到的文章＆＃34;在动态计划看起来很有希望的情况下，可以启发式地跳过成本比较。这主要发生在非常便宜的查询中，但细节是深奥的。＆＃34;

我认为第一种方法（没有额外的工作表填充步骤）更有效率，我是否正确？

这取决于。动态和静态游标计划有不同的优点和缺点。如果最终会触及所有行，则静态计划可能会表现得更好。稍等一下。

很明显，动态游标不支持TOP构造

这是事实。动态游标计划中的所有迭代器必须能够保存和恢复状态，向前和向后扫描，为每个输出行处理一个输入行，并且是非阻塞的。一般来说，Top不能满足所有这些要求;类CQScanTopNew未实现必要的Set/Get/Goto/Marker()和ReverseDirection()方法（等等）。

我还读过，动态游标往往比静态游标慢。

对于Transact-SQL游标，通常会触及大部分或全部游标集。保存和恢复动态查询计划的状态会产生相关成本。如果在每次调用时处理单行，并且最终触及所有行，则会最大化此保存/恢复开销。

静态游标具有制作集合副本的开销（这可能是大集合的主要因素），但每行检索成本非常小。键集的每行检索开销高于静态，因为它们必须外连接到源表以检索非键列。

当访问集合的相对较小部分和/或检索不是一次一行时，动态游标是最佳的。这是许多常见游标场景中的典型访问模式，而不是博客文章倾向于测试的那些：）

如果有人能够解释为什么第一个查询中的每个扫描都算作2个逻辑读取，这也可能非常有启发性

这取决于扫描保存状态的方式，以及读数的计算方式。

我前面提到过的文章提到动态游标使用标记。谁能解释一下这些是什么？它只是一个RID或CI键，还是其他不同的东西？

动态游标计划中的每个迭代器都存在标记，而不仅仅是访问方法。 ＆＃39;标记＆＃39;是在它停止时重新启动计划迭代器所需的所有状态信息。对于访问方法，RID或索引键（如有必要，带有uniquifier）是其中很重要的一部分，但无论如何都不是整个故事。