我有一個錯誤的統計數據和零散索引數據庫上的一個複雜的查詢。我感到困惑的是，當我檢查一個實際的查詢計劃時，我從一個具有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