Solved

SQL Server 2005 - "Select" cannot use optimum index

Posted on 2008-10-29
8
862 Views
Last Modified: 2008-11-04
I am using Microsoft SQL Server 2005.
There is a datetime column, sales_date, in the table sales.
I have created an index in the table: -
create index idx_sales on sales(sales_date)

When I issue the follow SQL: -
select * from sales where sales_date = '20081030'
The result prompt out immediately.  I figure out from the Execution Plan that it has used the correct index, idx_sales.

When I issue the follow SQL: -
select * from sales where sales_date between '20080801' and '20081030'
The result prompt out immediately, too.  The correct index, idx_sales is used.

However, when I issue the follow SQL: -
select * from sales where sales_date between '20080501' and '20081030'
(Any date range  more than two months)
The result come out very very slowly.  From the Execution Plan, the index of the primary key has been used.  (It means that "table scan" has been performed).

The table has been set as "IsAutoCreateStatistics" and "IsAutoUpdateStatistics".
So, why the correct index cannot be used?

Thx!

0
Comment
Question by:roland_lei
8 Comments
 
LVL 18

Expert Comment

by:jmoss111
ID: 22838244
How is the index ordered? I've found  that ordering by date descending makes a bit of difference on large tables.

Are all the columns really necessary?
0
 

Author Comment

by:roland_lei
ID: 22838442
The order of the index is decending.

All other columns are necessary.  Do other columns affect the correct selecting of index?
0
 
LVL 32

Expert Comment

by:bhess1
ID: 22838457
You have two options:

1)  Force the index (using index hints)

2)  Try alternate forms of the query, such as:

select * from sales where sales_date >= '20080501' and sales_date <= '20081030'

There can be quirks in the query optimizer that incorrectly affects the query plan.  Try 2 first, but if it does not work, try 1.
0
 
LVL 142

Expert Comment

by:Guy Hengel [angelIII / a3]
ID: 22838468
please try to rebuild the index, or defrag the index, or update the stats on the index...
0
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 

Author Comment

by:roland_lei
ID: 22838495
Rewriting as
select * from sales where sales_date >= '20080501' and sales_date <= '20081030
will have no change.

And I would not like to force the index because couple of programs should be amended.

I have dropped the index and recreate it and then update the statistics.  There is no change, too.
0
 
LVL 32

Expert Comment

by:bhess1
ID: 22841244
Sometimes the query analyzer simply fails to optimize correctly.  Do not assume that rewriting the query to use a different format will do nothing, as I have shown in my own queries that it can (but will not always, or even frequently) correct issues with bad query plans.

What is happening in this case is that the query analyzer is deciding that, with the number of records you are selecting, the end speed *should* be faster using a pk / clustered index (is the primary key clustered?) scan than it would be by using the index.

If you test by forcing the index, does the resulting query return more quickly than without in the poorly=performing case?  Or does it simply return the first rows faster, thus seeming more responsive, but take longer or more resources to complete the full query?
0
 

Author Comment

by:roland_lei
ID: 22850550
I have done two tests with different date ranges.

1st (shorter date range)
The time when running the full query with forcing index is 19 seconds.
The time when running the full query without forcing index is 39 seconds.

2nd (longer date range)
The time when running the full query with forcing index is 25 seconds.
The time when running the full query without forcing index is 44 seconds.

It means that the index is useful.  However, the query optimizer cannot use the appropriate index.
0
 
LVL 32

Accepted Solution

by:
bhess1 earned 500 total points
ID: 22869607
Yes, this would be a failure inside the optimizer code in SQL Server itself.   The statistics and assumptions used by the optimizer apparently do not handle this particular table and index structure as a completely optimized process.

The reasons can vary from excessive clustered index fragmentation in the table itself (i.e. if the file was completely defragmented, the clustered index would actually be faster, but since it is not, the end result is slower response time) to unusual data distribution (i.e. the optimizer looks at the statistics and decides that the data is not sufficiently selective for the period covered - a problem that may fix itself as more data is added to the table) to beyond threshold resource usage (i.e. the optimizer compares the resource usage of the queries - even though query 1 is faster, it may use more resources, and so the optimizer uses option 2) to simply a case of the assumptions and rules built into the optimizer code messing up on this specific example.

The index hints are available to handle the cases where the optimizer chooses a non-optimal method.  I think that's what you will need to do unless patching to a new SP or hotfix corrects the issue - and there is no guarantee that it will.
0

Featured Post

Zoho SalesIQ

Hassle-free live chat software re-imagined for business growth. 2 users, always free.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Data architecture is an important aspect in Software as a Service (SaaS) delivery model. This article is a study on the database of a single-tenant application that could be extended to support multiple tenants. The application is web-based develope…
In this article we will get to know that how can we recover deleted data if it happens accidently. We really can recover deleted rows if we know the time when data is deleted by using the transaction log.
Along with being a a promotional video for my three-day Annielytics Dashboard Seminor, this Micro Tutorial is an intro to Google Analytics API data.
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…

920 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now