我对具有
错误统计数据和碎片索引的
数据库进行了复杂
查询.我感到困惑的是,当我检查一个实际的
查询计划时,我从一个具有23 K行的表上的表扫描得到54 M行.
查询计划更进一步,这个表与自身相连(23 K中只有260 K行).这怎么可能?
运行一些其他查询或重建索引和统计数据会使这一点消失,我只是想了解为什么会发生这种情况.
我已经使用sql 2005和sql 2008 R2在同一数据库的还原上重现了这一点.
更新:是的,这是一个实际的计划.行数是20039(如上所述,不是23 K).这是最右边的节点之一.
看起来执行计划中的这个节点是嵌套循环连接中涉及的“第二”表,“first”表中有2701行(感谢Martin!).
由于在HistoricalPrice表上似乎没有适当的索引,因此必须针对循环连接中的每一行扫描堆,从而导致总共2701 * 20039 = 54,125,339行.从嵌套循环运算符出来的行数将是已加入/匹配的行的总数.
虽然执行计划仅显示作为一个节点访问的表,但循环连接最终将访问该表的次数与行数一样多.如果没有索引,则必须扫描整个表,每次返回20,039行返回到嵌套循环运算符.
如果在表上放置了适当的索引来支持连接,那么可能只搜索一行,因此将较少数量的行发送回嵌套循环.