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

Chapter 9: SQL Server Storage and Index Structures
A question that might come to mind is why ascending vs. descending matters — SQL Server can just
look at an index backwards if it needs the reverse sort order. Life is not, however, always quite so simple.
Looking at the index in reverse order works just fine if you’re dealing with only one column, or if your
sort is always the same for all columns, but what if you needed to mix sort orders within an index? That
is, what if you need one column to be sorted ascending, but the other descending? Since the indexed
columns are stored together, reversing the way you look at the index for one column would also reverse
the order for the additional columns. If you explicitly state that one column is ascending and the other is
descending, then you invert the second column right within the physical data — there is suddenly no
reason to change the way that you access your data.
As a quick example, imagine a reporting scenario where you want to order your employee list by the
hire date, beginning with the most recent (a descending order), but you also want to order by their last
name (an ascending order). Before indexes were available, SQL Server would have to do two operations
— one for the first column and one for the second. Having control over the physical sort order of
our data provides flexibility in the way we can combine columns.
INCLUDE
This one is supported with SQL Server 2005 and later. Its purpose is to provide better support for what
are called covered queries.
When you INCLUDE columns as opposed to placing them in the ON list, SQL Server only adds them at the
leaf level of the index. Because each row at the leaf level of an index corresponds to a data row, what
you’re doing is essentially including more of the raw data in the leaf level of your index. If you think
about this, you can probably make the guess that INCLUDE really applies only to non-clustered indexes
(clustered indexes already are the data at the leaf level, so there would be no point).
Why does this matter? Well, as we’ll discuss further as the book goes on, SQL Server stops working as
soon as it has what it actually needs. So if while traversing the index it can find all the data that it needs
without continuing to the actual data row, then it won’t bother going to the data row (what would be the
point?). By including a particular column in the index, you may “cover” a query that utilizes that particular
index at the leaf level and save the I/O associated with using that index pointer to go to the data page.
WITH
Careful not to abuse this one! When you include columns, you are enlarging the size of the leaf level of
your index pages. That means fewer rows will fit per page, and therefore, more I/O may be required to
see the same number of rows. The result may be that your effort to speed up one query may slow down
others. To quote an old film from the eighties, “Balance, Danielson — balance!” Think about the effects
on all parts of your system, not just the particular query you’re working on that moment.
WITH is an easy one; it just tells SQL Server that you will indeed be supplying one or more of the options
that follow.
PAD_INDEX
278
In the syntax list, this one comes first — but that will seem odd when you understand what PAD_INDEX
does. In short, it determines just how full the non-leaf level pages of your index are going to be (as a percentage)
when the index is first created. You don’t state a percentage on PAD_INDEX because it will use
whatever percentage you specify in the FILLFACTOR option that follows. Setting PAD_INDEX = ON
would be meaningless without a FILLFACTOR (which is why it seems odd that it comes first).