我应该使用查询提示Fast number\u rows/FASTFIRSTROW吗?

举一个快速的例子,考虑A和B之间的连接,用约束进行排序。假设先计算连接B,嵌套循环A遵循按顺序约束,因此将产生快速结果(无需排序),但由于基数的关系,成本更高(B有许多与WHERE匹配的记录,而A只有少数记录)。另一方面,首先计算B和嵌套循环A将生成一个IO更少的查询,因此总体上更快,但结果必须先排序,排序只能开始 之后 连接将被评估,因此第一个结果将很晚出现。优化器通常会选择第二个计划,因为总体上更高效。FAST提示将导致优化器选择第一个计划,因为它可以更快地生成结果。

x ,也没有好处 x . 查询优化器已经根据您检索的行数做出了决定。这同样适用于普通查询,例如从唯一索引查询特定值。

除此之外,, 什么时候可以帮忙 你 x ,但查询优化器没有。当然,如果查询优化器为结果很少的复杂查询选择了糟糕的路径,则可能需要更新统计信息。如果你猜错了 ,查询可能会花费更长的时间——在给出提示时几乎总是有风险的。

上述说法还没有得到检验——可能是这样的 全部的 查询完全执行所需的时间与完全执行所需的时间相同,如果不是更长的话。如果只有8行,那么快速获取前10行是很好的,但是理论上查询在完成之前仍然必须完全执行。我认为这样做的好处可能是因为查询执行采用了不同的路径 期望 记录,而事实上它真的是想得到第一个 x

对于那个特定的查询,当然不是!它只会返回一行 ID = 444 . SQL Server将尽可能高效地选择该行。

FAST 10