我正在阅读有关查询提示的文档：http: //msdn.microsoft.com/en-us/library/ms181714 (SQL.90).aspx
并注意到这一点： FAST number_rows 指定查询已针对快速检索第一个 number_rows 进行了优化。这是一个非负整数。返回第一个 number_rows 后，查询继续执行并生成完整的结果集。
所以当我做这样的查询时：
Select Name from Students where ID = 444
我应该打扰这样的提示吗？假设 SQL Server 2005，我应该什么时候？
- 编辑 -
在限制结果时也应该打扰：
Select top 10 * from Students OPTION (FAST 10)
FAST 提示仅对优化器可以选择的多种选择的复杂查询有意义。对于像您的示例这样的简单查询，它没有任何帮助，查询优化器将立即确定有一个简单的计划（在 ID 索引中查找，如果没有覆盖，则查找名称）来满足查询并执行它。即使 ID 上不存在索引，该计划仍然很简单（可能是集群扫描）。
举一个 FAST 有用的例子，考虑 A 和 B 之间的连接，带有 ORDER BY 约束。假设首先评估连接 B 并且嵌套循环 A 遵守 ORDER BY 约束，因此将产生快速结果（不需要 SORT），但由于基数而成本更高（B 有许多与 WHERE 匹配的记录，而 A 很少）。另一方面，首先评估 B 并且嵌套循环 A 会产生一个执行较少 IO 的查询，因此总体上更快，但是必须首先对结果进行排序，并且 SORT 只能在评估连接后开始，所以第一个结果会出现很晚了。优化器通常会选择第二个计划，因为总体上效率更高。FAST 提示将导致优化器选择第一个计划，因为它可以更快地产生结果。
使用TOP x时，也使用OPTION FAST x没有任何好处。查询优化器已经根据您要检索的行数做出决定。琐碎的查询也是如此，例如从唯一索引中查询特定值。
除此之外，当您知道结果数可能低于x时， OPTION FAST x可能会有所帮助，但查询优化器不会。当然，如果查询优化器为结果很少的复杂查询选择了较差的路径，则可能需要更新您的统计信息。如果你在x上猜错了，查询可能最终会花费更长的时间——在给出提示时几乎总是有风险。
上述语句尚未经过测试——可能所有查询都需要同样长的时间才能完全执行，如果不是更长的话。如果只有 8 行，快速获取前 10 行是很好的，但理论上查询仍然必须在完成之前完全执行。我在想的好处可能就在那里，因为查询执行采用了不同的路径，期望总记录更少，而实际上它实际上是在尝试更快地获得第一个x 。这两种类型的优化可能不一致。
对于那个特定的查询，当然不是！它只会返回一行——带有ID = 444. SQL Server 将尽可能有效地选择该行。
FAST 10可能在您可以立即使用前 10 行的情况下使用，即使您继续等待进一步的结果。