对于我正在尝试优化的中等复杂查询，我注意到删除TOP n子句会更改执行计划。我会猜到，当查询包含TOP n数据库引擎时会忽略该TOP子句运行查询，然后最后将该结果集缩小到请求的n行数。图形执行计划似乎表明情况就是这样——TOP是“最后”一步。但似乎还有更多的事情发生。
我的问题是，TOP n 子句如何（以及为什么）影响查询的执行计划？
这是我的情况的简化版本：
该查询匹配两个表 A 和 B 中的行。
如果没有该TOP子句，优化器估计表 A 中将有 19k 行，表 B 中将有 46k 行。返回的实际行数是 A 的 16k 和 B 的 13k。哈希匹配用于连接这两个结果集以获得总共 69 行（然后应用排序）。这个查询发生得很快。
当我添加TOP 1001优化器时不使用哈希匹配；相反，它首先对表 A 中的结果进行排序（相同的估计/实际为 19k/16k）并针对表 B 执行嵌套循环。表 B 的估计行数现在为 1，奇怪的是TOP n直接影响针对 B 的估计执行次数（索引搜索）——它似乎总是2n+1，或者在我的情况下是 2003 。如果我改变，这个估计会相应地改变TOP n。当然，由于这是一个嵌套连接，实际执行次数为 16k（表 A 中的行数），这会减慢查询速度。
查询有一个ORDER BY子句。在计划中发生这种排序的位置添加TOP更改，但我更关心它如何影响对表 B 执行索引搜索的次数。
实际情况要复杂一些，但这抓住了基本的想法/行为。两个表都使用索引搜索进行搜索。这是 SQL Server 2008 R2 企业版。