我有一个错误的统计数据和零散索引数据库上的一个复杂的查询。我感到困惑的是，当我检查一个实际的查询计划时，我从一个具有23 K行的表的表扫描得到54 M行。查询计划的更深层次在于本表与其自身相结合（23 K中只有260 K行）。这怎么可能？表扫描如何返回比表中的行更多的行？
运行一些其他查询或重建索引和统计数据使得这消失，我只是想了解为什么会发生这种情况。
我已经使用SQL 2005和SQL 2008 R2对同一数据库进行了还原。
更新：是的，这是一个实际的计划。行数是20039（不是上面提到的23 K）。这是最右边的节点之一。
看起来好像在执行计划中这个节点是参与嵌套循环的“第二”表中的“第一”表时，用2701行（感谢马丁！）。
由于在HistoricalPrice表上似乎没有合适的索引，因此必须对循环连接中的每一行扫描堆，从而产生总计2701 * 20039 = 54,125,339行。来自嵌套循环运算符的行数将是连接/匹配行的总数。
尽管执行计划只显示被访问的表作为一个节点，但循环连接将最终访问该表的次数与存在行的次数相同。如果没有索引，则必须扫描整个表格，每次返回20,039行返回到嵌套循环操作符。
如果在表上放置了适当的索引以支持连接，那么可能只会查找单个行，并因此将少量行发送回嵌套循环。
是的，在树的更上方有一个嵌套循环，另一侧请求2701行。 – PavelR 2011-05-27 14:24:47
嗯......表格被多次扫描？ – 2011-05-26 19:44:06
由于很好的理由，该表在查询中自加入。在查询计划中，它会被扫描两次（上面提到的表扫描），并且还会在表格中进行三次索引查找。 – PavelR 2011-05-26 19:51:09
这是估计的执行计划，还是实际执行计划？ – Ryk 2011-05-26 23:14:31