sql server - Extrememly High Estimated Number of Rows in Execution Plan -
i have stored procedure running 10 times slower in production in staging. took @ @ execution plan , first thing noticed cost on table insert (into table variable @temp) 100% in production , 2% in staging.
the estimated number of rows in production showed 200 million row! in staging 33.
although production db running on sql server 2008 r2 while staging sql server 2012 don't think difference cause such problem.
what cause of such huge difference?
updated
added execution plan. can see, large number of estimated rows shows in nested loops (inner join) clustered index seek table.
updated2
link plan xml included plan.xml
and sql sentry plan explorer view (with estimated counts shown)
this looks bug me.
there estimated 90,991.1
rows going nested loops.
the table cardinality of table being seeked on 24,826
.
90,991.1 * 24,826 * 10% = 225,894,504.86
pretty close estimated rows of 225,894,000
but execution plan shows 1
row estimated per seek. not 24,826
above.
so these figures don't add up. assume starts off original 10% ball park estimate , later adjusts 1 because of presence of unique constraint without making compensating adjustment other branches.
i see seek calling scalar udf [dbo].[tryconvertguid]
able reproduce similar behavior on sql server 2005 seeking on unique index on inside of nested loops predicate being udf produced result number of rows estimated out of join larger expected multiplying estimated seeked rows * estimated number of executions.
but, in case, operators left of problematic part of plan pretty simple , not sensitive number of rows (neither rowcount top operator or insert operator change) don't think quirk responsible performance issues noticed.
regarding point in comments answer switching temp table helped performance of insert may because allows read part of plan operate in parallel (inserting table variable block this)
Comments
Post a Comment