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

Chapter 9: SQL Server Storage and Index Structures
As you can see, it looks essentially identical to the more generic B-Trees we discussed earlier in the chapter.
In this case, we’re doing a range search (something clustered indexes are particularly good at) for
numbers 158–400. All we have to do is navigate to the first record and include all remaining records on
that page. We know we need the rest of that page because the information from the node one level up
lets us know that we’ll also need data from a few other pages. Because this is an ordered list, we can be
sure it’s continuous — that means if the next page has records that should be included, then the rest of
this page must be included. We can just start spewing out data from those pages without having to do
any verification.
We start off by navigating to the root node. SQL Server is able to locate the root node based on an entry
that you can see in the system metadata view called sys.indexes.
By looking through the page that serves as the root node, we can figure out what the next page we need
to examine is (the second page on the second level as we have it drawn here). We then continue the
process. With each step we take down the tree, we are getting to smaller and smaller subsets of data.
Eventually, we will get to the leaf level of the index. In the case of our clustered index, getting to the leaf
level of the index means that we are also at our desired row(s) and our desired data.
Non-Clustered Indexes on a Heap
272
I can’t stress enough the importance of this distinction: With a clustered index, when
you’ve fully navigated the index, you’ve fully navigated to your data. How much of
a performance difference this can make will really show its head as we look at nonclustered
indexes — particularly when the non-clustered index is built over a clustered
index.
Non-clustered indexes on a heap work very similarly to clustered indexes in most ways. They do, however,
have a few notable differences:
The leaf level is not the data — instead, it is the level at which you are able to obtain a pointer to that
data. This pointer comes in the form of a row identifier or RID, which, as we described earlier in the
chapter, is made up of the extent, page, and row offset for the particular row being pointed to by the
index. Even though the leaf level is not the actual data (instead, it has the RID), we only have one more
step than with a clustered index. Because the RID has the full information on the location of the row, we
can go directly to the data.
Don’t, however, misunderstand this “one more step” to mean that there’s only a small amount of overhead
difference and that non-clustered indexes on a heap will run close to as fast as a clustered index.
With a clustered index, the data is physically in the order of the index. That means, for a range of data,
when you find the row that has the beginning of your data on it, there’s a good chance that the other
rows are on that page with it (that is, you’re already physically almost to the next record since they are
stored together). With a heap, the data is not linked together in any way other than through the index.
From a physical standpoint, there is absolutely no sorting of any kind. This means that from a physical
read standpoint, your system may have to retrieve records from all over the file. Indeed, it’s quite possible
(possibly even probable) that you will wind up fetching data from the same page several separate
times. SQL Server has no way of knowing it will have to come back to that physical location because