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