OPTION (FAST 1) 实际上如何与客户端交互？

Question

这是 2 个问题中的第 1 个问题，与 OPTION (FAST 1);

我们刚刚将 ERP 数据库从 SQL 2000 EE 升级到 2008 R2 EE，我们注意到数据库中的阻塞有所增加。我已将其范围缩小到我认为是供应商代码中的违规语句，即：

SELECT MAX(column)
FROM [table] 
WHERE <condition> 
OPTION (FAST 1);

spid 留下一个打开的事务并锁定表，阻塞所有其他客户端。但是，调用客户端似乎不再与服务器交互以告诉服务器它已收到结束会话的数据。

阅读有关 Query Hints的文档，我看到了这个声明

FAST number_rows

指定为快速检索第一个 number_rows 优化查询。这是一个非负整数。返回第一个 number_rows 后，查询将继续执行并生成其完整结果集。

这让我想知道客户端是否以某种方式中断了通信，服务器是否会保持事务打开，n在返回第一行后处理完整的结果集并使事务保持打开状态？该流程是一个内部流程，因此我无法真正看到最终用户执行会话来执行此操作，而且这并不是每次发生内部流程时都会发生的事情。但是，它只被内部进程使用。

阅读了Remus对 SO的回答后，对于查询的简单性来说，这似乎是矫枉过正。查看查询，如果他们从未分组的结果中收到更多的结果，MAX那么事情就很可疑了。

因此，当我准备与供应商合作时，我想知道是否可以开始准确地将我们的阻塞问题归结为正在使用此查询提示的事实。

请随时编辑/请求编辑，因为我知道这实际上可能不清楚。

Answer 1

如果它是一个返回超过 1 行的查询，我推测供应商中的某个人（回到过去，考虑到 SQL Server 的版本）偶然发现了查询优化器，当FAST被指定为提示时产生了一个更可取的计划。

由于它仅返回 1 行，因此该解释可能与无限猴子定理有更多共同点，而不是合理判断。一位大三学生看到了一个提示，FAST并认为这比他的查询速度不快要好。

这让我想知道客户端是否以某种方式中断了通信，服务器是否会保持事务打开，在返回前 n 行后处理完整的结果集并使事务保持打开状态？

查询返回 1 行，因此没有进一步的结果集要处理。我倾向于怀疑堆栈上还有其他代码导致了问题。