SQL 执行计划显示“实际行数” 比桌子尺寸大
我有一个相当复杂的联接的执行计划，它显示在表上执行索引查找，“实际行数”读数约为 70,000，而实际上表中总共只有约 600 行（估计行数）行数仅为 127)。
请注意，所有统计信息都是最新的，并且查询的输入参数与编译过程时输入的参数完全相同。
为什么实际行数如此之高，“实际行数”这个数字的真正含义是什么？
我唯一的理论是，大量行与嵌套循环有关，并且此索引查找正在执行多次 - “实际行数”实际上代表所有执行的总行数。 如果是这种情况，估计的行数是否也意味着所有执行的总行数？
I have an execution plan for a fairly complex join which shows an index seek being performed on a table with the "Actual Number of Rows" reading ~70,000, when there are in fact only ~600 rows in the table in total (the estimated number of rows is only 127).
Note that all of the statistics are up to date and the input parameters to the query are exactly the same as the parameters that were entered when the proc was compiled.
Why is the actual number of rows so high, and what does the number "Actual Number of Rows" really mean?
My only theory is that high number of rows is related to the nested loops, and that this index seek is being executed a number of times - the "Actual Number of Rows" really represents the total number of rows over all executions. If this is the case is the estimated number of rows also meant to be the total number of rows over all executions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
ActualRows 计算物理运算符调用 GetNext() 的次数。
您还应该查看ActualRebinds、ActualRewinds 和 ActualEndOfScans 来了解一下内部循环被重新评估了多少次：
ActualRows counts the number of times GetNext() was called on a physical operator.
You should also look at the ActualRebinds, ActualRewinds and ActualEndOfScans to get an idea how many times the inner loop was re-evaluated:
实际行数值是执行计划中该节点的所有处理值的结果。 所以是的，它考虑了嵌套循环连接。
the actual number of rows values is the result of all processed values for that node in the exec plan. so yes it takes into account the nested loops join.