views:

191

answers:

4

I have a table (SQL 2000) with over 10,000,000 records. Records get added at a rate of approximately 80,000-100,000 per week. Once a week a few reports get generated from the data. The reports are typically fairly slow to run because there are few indexes (presumably to speed up the INSERTs). One new report could really benefit from an additional index on a particular "char(3)" column.

I've added the index using Enterprise Manager (Manage Indexes -> New -> select column, OK), and even rebuilt the indexes on the table, but the SELECT query has not sped up at all. Any ideas?

Update:

Table definition:

ID, int, PK
Source, char(3)  <--- column I want indexed
...
About 20 different varchar fields
...
CreatedDate, datetime
Status, tinyint
ExternalID, uniqueidentifier

My test query is just:

select top 10000 [field list] where Source = 'abc'
A: 

For a table of that size your best bet is probably going to be partitioning your table and indexes.

Brad Barker
Do you have any idea how much effect this would have? How can you say "probably"? How probable? How much effort should they spend? How would they weigh whether it's a good idea? It sounds a lot like "try this, try that".
le dorfier
It will have an effect, but I have no way to tell you how much. Is it better to use a HashTable or search sequentially through a list when looking for an item? Divide and conquer works. That's CS1.
Brad Barker
CS1 is *not* that you should probably partition your big tables and indexes because it might help.
le dorfier
It's going to hurt on inserts, but you are telling me it won't help on reads? Seriously?
Brad Barker
I'm saying it's a matter of how much hurt, and how much help. It's not worth all the implementation and support overhead for a .05% gain; which is entirely possible. I'm saying your suggestion is pretty random if you don't qualify or compare it and just say "probably", as if it were obvious.
le dorfier
+1  A: 

Use the Show Execution Plan in SQL Query Analyzer to see if the index is used.

You could also try making it a clustered index if it isn't already.

Jonas Elfström
+5  A: 

You need to look at the query plan and see if it is using that new index - if it isnt there are a couple things. One - it could have a cached query plan that it is using that has not been invalidated since the new index was created. If that is not the case you can also trying index hints [ With (Index (yourindexname)) ].

10,000,000 rows is not unheard of, it should read that out pretty fast.

keithwarren7
"it should read that out pretty fast" that's a bold statement, given the fact that you know zero about the hardware configuration, SQL server version, RAM amount , other load, disk setup, ...)
Tomalak
This was the "hint" I needed (pun intended). Query now runs in < 2 seconds. Thank you.
daughtkom
Tomalak - good point. I was just making a general assumption but it seems that he was successful.
keithwarren7
So I think this shows that the index was not used automatically because of it's low selectivity, and a full table scan occurred instead.
Tomalak
I would be interested to see if after providing the hint, if he ran the query without the hint if the QP changed its plan to scan that index. I doubt it is a cardinality issue with 10m records but he never told us about that column itself and what it represented.
keithwarren7
If I run it with the hint then again without the hint, it is still slow without it.
daughtkom
A: 
 select top 10000

How unique are your sources? Indexes on fields that have very few values are usually ignore by the SQL engine. They make queries slower. You might want to remove that index and see if it is faster if your SOURCE field only has a handful of values.

jmucchiello