FIX: Optimizer Chooses Inefficient Clustered Index on Query with Date Range Condition
This article was previously published under Q246474
This article has been archived. It is offered "as is" and will no longer be updated.
BUG #: 56775 (SQLBUG_70)
When executing a query with a WHERE clause that references a date column that has a clustered index and any other column having a non-clustered index, SQL Server may choose an inefficient clustered index resulting in excessive response time to the user.
The optimizer chooses an inefficient clustered index. Forcing a non-clustered index gives much better performance in a simple SELECT statement with 2 search arguments (SARGs), one of which is a DATE range.
If a table has a clustered index on date column (column1) and non-clustered index on any other column (column2) and you perform a simple SELECT on the table with WHERE condition BETWEEN date range (column1) AND column2 = 'value' like this:
The optimizer choses the clustered index on column1 even though use of a non-clustered index on column2 gives better performance. That is, less CPU time and logical reads.
select * from table1where column1 between 'date1' and 'date2' and column2 = 'value'
Force the non-clustered index using a table hint.
Microsoft has confirmed this to be a problem in SQL Server 7.0. This problem has been corrected in U.S. Service Pack 2 for Microsoft SQL Server 7.0. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
254561 INF: How to Obtain Service Pack 2 for Microsoft SQL Server 7.0 and Microsoft Data Engine (MSDE) 1.0For more information, contact your primary support provider.
Article ID: 246474 - Last Review: 10/22/2013 02:49:39 - Revision: 2.1
Microsoft SQL Server 7.0 Standard Edition
- kbnosurvey kbarchive kbbug kbfix KB246474