Table row fluctuation & performance

Can the row-count fluctuation in a table cause a query to perform slowly?

Detailed explanation:

If a SQL Server table has regular inserts then deletes sometimes and then more inserts causing the total-row count to always change in that table cause a SELECT query to chose different execution plans and cause delays?

I've had situations where my SELECT query has run in 12-14 seconds while sometimes run for 40-240 minutes on a table which has indexes created additionally including the original ones, covering indexes, statistics updated, etc.

As an fyi, the query itself was presented on the forums and shown to multiple senior SQL experts and none found anything exceptional about this simple SELECT query using joins & subqueries in the where clause.

more ▼

asked Oct 25, 2009 at 06:22 PM in Default

avatar image

1.3k 75 104 147

No answer, just a comment that I've seen other people mention a similar problem in SQL 2005 environments. Our dbas are recompiling tables to force the various objects to go back to a correct plan.

Oct 25, 2009 at 07:08 PM Bob Hovious

Is the statement inside a stored procedure? Is the subquery correlated? Maybe you can add your statement in the question.

Oct 26, 2009 at 08:46 AM Håkan Winther
(comments are locked)
10|1200 characters needed characters left

2 answers: sort voted first

Out-of-date statistics can cause the Query Optimizer to make the wrong decision about how to run a query, but the amount of contrast you're describing is certainly extreme. I would recommend forcing a particular plan in this situation. It seems as if you've found one of the bugs in the Query Optimizer.

The other thing that could cause it to be painfully slow could be locking. If the query is hitting an object that is locked by another process (for example, someone's updated some data and hasn't ended the transaction yet), then that could stop the query for a long period. Have you looked into blocking when that query is running? If it's a problem, then consider using snapshot isolation instead, or weighing up the pain of NOLOCK.

more ▼

answered Oct 25, 2009 at 07:27 PM

avatar image

Rob Farley
5.8k 16 22 28

(comments are locked)
10|1200 characters needed characters left

It could simply be an issue of contention, more then one resource vieing for pages in the table and blocking each other, especially if you're doing that many inserts & deletes. But it's probably statistics. The trick will be to capture the execution plan of the query when it's running slowly and comparing it to when it's running normally. If they're the same, it's probably blocking of some sort.

The way I'd suggest capturing it, since you don't know for sure when it's going to occur, is to query the dynamic management view sys.dm_exec_query_plan.

more ▼

answered Oct 25, 2009 at 10:48 PM

avatar image

Grant Fritchey ♦♦
137k 20 47 81

(comments are locked)
10|1200 characters needed characters left
Your answer
toggle preview:

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

SQL Server Central

Need long-form SQL discussion? SQLserverCentral.com is the place.



asked: Oct 25, 2009 at 06:22 PM

Seen: 2195 times

Last Updated: Oct 25, 2009 at 06:22 PM

Copyright 2018 Redgate Software. Privacy Policy