Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 9: SQL Server Storage and Index Structures
Summary
296
Indexes are sort of a cornerstone topic in SQL Server or any other database environment, and are not
something to be taken lightly. They can drive your performance successes, but they can also drive your
performance failures.
Top-level things to think about with indexes:
❑ Clustered indexes are usually faster than non-clustered indexes (one could come very close to
saying always, but there are exceptions).
❑ Only place non-clustered indexes on columns where you are going to get a high level of selectivity
(that is, 95 percent or more of the rows are unique).
❑ All Data Manipulation Language (DML: INSERT, UPDATE, DELETE, SELECT) statements can benefit
from indexes, but inserts, deletes, and updates (remember, they use a delete and insert approach)
are slowed by indexes. The lookup part of a query is helped by the index, but anything that modifies
data will have extra work to do (to maintain the index in addition to the actual data).
❑ Indexes take up space.
❑ Indexes are used only if the first column in the index is relevant to your query.
❑ Indexes can hurt as much as they help — know why you’re building the index, and don’t build
indexes you don’t need.
❑ Indexes can provide structured data performance to your unstructured XML data, but keep in
mind that like other indexes, there is overhead involved.
When you’re thinking about indexes, ask yourself these questions:
Question Response
Are there a lot of inserts or
modifications to this table?
Is this a reporting table? That is,
not many inserts, but reports
run lots of different ways?
Is there a high level of selectivity
on the data?
Have I dropped the indexes I no
longer need?
Do I have a maintenance strategy
established?
If yes, keep indexes to a minimum. This kind of table usually
has modifications done through single-record lookups of the
primary key, and usually, this is the only index you want on
the table. If the inserts are non-sequential, think about using
something other than a clustered index.
More indexes are fine. Target the clustered index to frequently
used information that is likely to be extracted in ranges.
OLAP installations will often have many times the number of
indexes seen in an OLTP environment.
If yes, and it is frequently the target of a WHERE clause, then
add that index.
If not, why not?
If not, why not?