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

isn’t room on the page, SQL Server is going to see AR000001 in the table and know that it’s not a sequential
insert. Half the records from the old page will be copied to a new page before AP000025 is inserted.
The overhead of this can be staggering. Remember that we’re dealing with a clustered index, and that
the clustered index is the data. The data is in index order. This means that when you move the index to a
new page, you are also moving the data. Now imagine that you’re running this accounting system in a
typical OLTP environment (you don’t get much more OLTP-like than an accounting system) with a
bunch of data-entry people keying in vendor invoices or customer orders as fast as they can. You’re going
to have page splits occurring constantly, and every time you do, you’re going to see a brief hesitation for
users of that table while the system moves data around.
Fortunately, there are a couple of ways to avoid this scenario:
❑ Choose a cluster key that is going to be sequential in its inserting. You can either create an identity
column for this, or you may have another column that logically is sequential to any transaction
entered regardless of the system.
❑ Choose not to use a clustered index on this table. This is often the best option in a situation like
this, since an insert into a non-clustered index on a heap is usually faster than one on a cluster key.
Even as I’ve told you to lean toward sequential cluster keys to avoid page splits, you also have to realize
that there’s a cost there. Among the downsides of sequential cluster keys are concurrency (two or more
people trying to get to the same object at the same time). It’s all about balancing out what you want,
what you’re doing, and what it’s going to cost you elsewhere.
This is perhaps one of the best examples of why I have gone into so much depth about how things work.
You need to think through how things are actually going to get done before you have a good feel for
what the right index to use (or not to use) is.
Column Order Matters
Chapter 9: SQL Server Storage and Index Structures
Just because an index has two columns, it doesn’t mean that the index is useful for any query that refers
to either column.
An index is only considered for use if the first column listed in the index is used in the query. The bright
side is that there doesn’t have to be an exact one-for-one match to every column — just the first. Naturally,
the more columns that match (in order), the better, but only the first creates a definite do-not-use
situation.
Think about things this way. Imagine that you are using a phone book. Everything is indexed by last
name and then first name — does this sorting do you any real good if all you know is that the person
you want to call is named Fred? On the other hand, if all you know is that his last name is Blake, the
index will still serve to narrow the field for you.
One of the more common mistakes that I see in index construction is the belief that one index that includes
all the columns is going to be helpful for all situations. Indeed, what you’re really doing is storing all the
data a second time. The index will totally be ignored if the first column of the index isn’t mentioned in
the JOIN, ORDER BY, or WHERE clauses of the query.
287