x

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

Slick84 gravatar image

Slick84
1.3k 75 102 142

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

Rob Farley gravatar image

Rob Farley
5.7k 16 18 20

I vote for this answer and I recommend you to also investigate index fragmentation on any of the tables involved.
Oct 26, 2009 at 05:50 AM Håkan Winther
(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

Grant Fritchey gravatar image

Grant Fritchey ♦♦
103k 19 21 74

(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.

New code box

There's a new way to format code on the site - the red speech bubble logo will automatically format T-SQL for you. The original code box is still there for XML, etc. More details here.

Follow this question

By Email:

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

By RSS:

Answers

Answers and Comments

SQL Server Central

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

Topics:

x990
x251
x12

asked: Oct 25, 2009 at 06:22 PM

Seen: 1911 times

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