Running Microsoft SQL Server Profiler every now and then, it suggests me with a bunch of new indexes and statistics to create ("...97% estimated improvement...").
From my understanding every added index can make an SQL SELECT query faster but also an UPDATE or INSERT query slower since the indexes have to be adjusted.
What I wonder is, when do I have "too many" indexes/statistics?
Maybe there is no clear answer on this but some rule-of-thumb.
Your load profile is the most important factor in answering this question.
If your load is read-intensive, you want indexes to satisfy your heaviest or most frequent queries.
If your load is write-intensive, index carefully. Index to satisfy a seek an UPDATE needs, for example, as well as your one or two most expensive SELECTs.
If your load is an OLAP one, index sparingly since you will be scanning the target tables anyway.
How do you know you have too many indexes?
When you can see that some of them are not used by any queries.
A frequent DELETE, UPDATE or INSERT shows a query plan that involves several expensive index changes (i.e. a nonclustered index insert, update, or delete). Use your judgement to determine if the penalty on those DML statements is worth the gain you are getting from the indexes that have to be updated.
If you have indexes which are being maintained but are never being used (or are rarely being used) then you have to many indexes. If all your indexes are being used to improve user performance then you don't have to many.
UPDATEandINSERTstatements too slow. – Uwe Keim Sep 8 '11 at 15:11