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

Chapter 9: SQL Server Storage and Index Structures
274
At the leaf level, we have a rather sharp difference from what we’ve seen with the other two index structures:
We have yet another index to look over. With clustered indexes, when we got to the leaf level, we
found the actual data. With non-clustered indexes on a heap, we didn’t find the actual data, but did find
an identifier that let us go right to the data (we were just one step away). With non-clustered indexes on
a clustered table, we find the cluster key. That is, we find enough information to go and make use of the
clustered index.
We end up with something that looks like Figure 9-7.
What we end up with is two entirely different kinds of lookups.
In the example from our diagram, we start off with a ranged search. We do one single lookup in our
index and are able to look through the non-clustered index to find a continuous range of data that meets
our criterion (LIKE ‘T%’). This kind of lookup, where we can go right to a particular spot in the index,
is called a seek.
The second kind of lookup then starts — the lookup using the clustered index. This second lookup is
very fast; the problem lies in the fact that it must happen multiple times. You see, SQL Server retrieved a
list from the first index lookup (a list of all the names that start with “T”), but that list doesn’t logically
match up with the cluster key in any continuous fashion. Each record needs to be looked up individually,
as shown in Figure 9-8.
Needless to say, this multiple-lookup situation introduces more overhead than if we had just been able to
use the clustered index from the beginning. The first index search — the one through our non-clustered
index — requires very few logical reads.
For example, if I have a table with 1,000 bytes per row and I do a lookup similar to the one in our drawing
(say, something that would return five or six rows); it would only take something to the order of
8–10 logical reads to get the information from the non-clustered index. However, that only gets me as far
as being ready to look up the rows in the clustered index. Those lookups would cost approximately 3–4
logical reads each, or 15–24 additional reads. That probably doesn’t seem like that big a deal at first, but
look at it this way:
Logical reads went from 3 minimum to 24 maximum — that’s an 800 percent increase in the amount of
work that had to be done.
Now expand this thought out to something where the range of values from the non-clustered index wasn’t
just five or six rows, but five or six thousand, or five or six hundred thousand rows — that’s going to be a
huge impact.
Don’t let the extra overhead vs. a clustered index scare you — the point isn’t meant to scare you away
from using indexes, but rather to point out that a non-clustered index is generally not going to be as
efficient as a clustered index from a read perspective (it can, in some instances, actually be a better
choice at insertion time). An index of any kind is usually (there are exceptions) the fastest way to do a
lookup. We’ll explain what index to use and why later in the chapter.