SQL Execution Plan shows an "Actual Number of Rows" which is larger than the table size.

Question

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?

Answer 1

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.

Answer 2

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:

A rebind means that one or more of the correlated parameters of the join changed and the inner side must be reevaluated. A rewind means that none of the correlated parameters changed and the prior inner result set may be reused.