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

Chapter 9: SQL Server Storage and Index Structures
The Pros
Clustered indexes are best for queries when the column(s) in question will frequently be the subject of
a ranged query. This kind of query is typified by use of the BETWEEN statement or the < or > symbols.
Queries that use a GROUP BY and make use of the MAX, MIN, and COUNT aggregators are also great examples
of queries that use ranges and love clustered indexes. Clustering works well here because the search can
go straight to a particular point in the physical data, keep reading until it gets to the end of the range,
and then stop. It is extremely efficient.
Clusters can also be excellent when you want your data sorted (using ORDER BY) based on the cluster key.
The Cons
286
There are two situations in which you don’t want to create that clustered index. The first is fairly
obvious — when there’s a better place to use it. I know I’m sounding repetitive here, but don’t use a
clustered index on a column just because it seems like the thing to do (primary keys are the common
culprit here). Be sure that you don’t have another column that it’s better suited to first.
Perhaps the much bigger no-no use for clustered indexes, however, is when you are going to be doing a
lot of inserts in a non-sequential order. Remember that concept of page splits? Well, here’s where it can
come back and haunt you big time.
Imagine this scenario: You are creating an accounting system. You would like to make use of the concept
of a transaction number for your primary key in your transaction files, but you would also like those
transaction numbers to be somewhat indicative of what kind of transaction it is (it really helps trouble -
shooting for your accountants). So you come up with something of a scheme — you’ll place a prefix on
all the transactions indicating what sub-system they come out of. They will look something like this:
ARXXXXXX Accounts Receivable Transactions
GLXXXXXX General Ledger Transactions
APXXXXXX Accounts Payable Transactions
where XXXXXX will be a sequential numeric value.
This seems like a great idea, so you implement it, leaving the default of the clustered index going on the
primary key.
At first glance, everything about this setup looks fine. You’re going to have unique values, and the
accountants will love the fact that they can infer where something came from based on the transaction
number. The clustered index seems to make sense since they will often be querying for ranges of transaction
IDs.
Ah, if only it were that simple. Think about your inserts for a bit. With a clustered index, we originally
had a nice mechanism to avoid much of the overhead of page splits. When a new record was inserted
that was to go after the last record in the table, then even if there was a page split, only that record would
go to the new page — SQL Server wouldn’t try and move around any of the old data. Now we’ve messed
things up though.
New records inserted from the General Ledger will wind up going on the end of the file just fine (GL is
last alphabetically, and the numbers will be sequential). The AR and AP transactions have a major problem
though — they are going to be doing non-sequential inserts. When AP000025 gets inserted and there