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

Chapter 9: SQL Server Storage and Index Structures
Selectivity
Indexes, particularly non-clustered indexes, are primarily beneficial in situations where there is a reasonably
high level of selectivity within the index. By selectivity, I’m referring to the percentage of values in
the column that are unique. The higher the percentage of unique values within a column, the higher the
selectivity is said to be, and the greater the benefit of indexing.
If you think back to our sections on non-clustered indexes — particularly the section on non-clustered
indexes versus a clustered index — you will recall that the lookup in the non-clustered index is really
only the beginning. You still need to make another loop through the clustered index in order to find the
real data. Even with the non-clustered index on a heap, you still end up with multiple physically separate
reads to perform.
If one lookup in your non-clustered index is going to generate multiple additional lookups in a clustered
index, then you are probably better off with the table scan. The exponential effect that’s possible here is
actually quite amazing. Consider that the looping process created by the non-clustered index is not
worth it if you don’t have somewhere in the area of 90–95 percent uniqueness in the indexed column.
Clustered indexes are substantially less affected by this because, once you’re at the start of your range of
data — unique or not — you’re there. There are no additional index pages to read. Still, more than likely,
your clustered index has other things for which it could be put to greater use.
One other exception to the rule of selectivity has to do with foreign keys. If your table has a column that
is a foreign key, then in all likelihood, you’re going to benefit from having an index on that column.
Why foreign keys and not other columns? Well, foreign keys are frequently the target of joins with
the table they reference. Indexes, regardless of selectivity, can be very instrumental in join performance
because they allow what is called a merge join. A merge join obtains a row from each table and compares
them to see if they match the join criteria (what you’re joining on). Since there are indexes on the
related columns in both tables, the seek for both rows is very fast.
The point here is that selectivity is not everything, but it is a big issue to consider. If the column in
question is not in a foreign key situation, then it is almost certainly the second only to the, “How often
will this be used?” question in terms of issues you need to consider.
Watching Costs: When Less Is More
284
Remember that while indexes speed up performance when reading data, they are actually very costly
when modifying data. Indexes are not maintained by magic. Every time that you make a modification to
your data, any indexes related to that data also need to be updated.
When you insert a new row, a new entry must be made into every index on your table. Remember, too,
that when you update a row, it is handled as a delete and insert — again, your indexes have to be
updated. But wait! There’s more! (Feeling like a late-night infomercial here.) When you delete records,
again, you must update all the indexes, too — not just the data. For every index that you create, you are
creating one more block of entries that have to be updated.
Notice, by the way, that I said entries plural — not just one. Remember that a B-Tree has multiple levels
to it. Every time that you make a modification to the leaf level, there is a chance that a page split will