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

You may hear lots of bad things about table scans, and in general, they will be true. However, table scans
can actually be the fastest method of access in some instances. Typically, this is the case when retrieving
data from rather small tables. The exact size where this becomes the case will vary widely according to
the width of your table and the specific nature of the query.
See if you can spot why the use of EXISTS in the WHERE clause of your queries has so much to offer
performance-wise when it fits the problem. When you use the EXISTS operator, SQL Server stops as
soon as it finds one record that matches the criteria. If you had a million-record table and it found a
matching record on the third record, then use of the EXISTS option would have saved you the reading
of 999,997 records! NOT EXISTS works in much the same way.
Use of Indexes
When SQL Server decides to use an index, the process actually works somewhat similarly to a table scan,
but with a few shortcuts.
During the query optimization process, the optimizer takes a look at all the available indexes and
chooses the best one (this is primarily based on the information you specify in your joins and WHERE
clause, combined with statistical information SQL Server keeps on index makeup). Once that index is
chosen, SQL Server navigates the tree structure to the point of data that matches your criteria and again
extracts only the records it needs. The difference is that since the data is sorted, the query engine knows
when it has reached the end of the current range it is looking for. It can then end the query, or move on
to the next range of data as necessary.
If you ponder the query topics we’ve studied thus far (Chapter 7 specifically), you may notice some
striking resemblances to how the EXISTS option works. The EXISTS keyword allowed a query to quit
running the instant that it found a match. The performance gains using an index are similar or better
than EXISTS since the process of searching for data can work in a similar fashion; that is, the server can
use the sort of the index to know when there is nothing left that’s relevant and can stop things right
there. Even better, however, is that by using an index, we don’t have to limit ourselves to Boolean situations
(does the piece of data I was after exist — yes or no?). We can apply this same notion to both the
beginning and end of a range. We are able to gather ranges of data with essentially the same benefits that
using an index gives to finding data. What’s more, we can do a very fast lookup (called a SEEK) of our
data rather than hunting through the entire table.
Don’t get the impression from my comparing what indexes do to what the EXISTS operator does that
indexes replace the EXISTS operator altogether (or vice versa). The two are not mutually exclusive; they
can be used together, and often are. I mention them here together only because they have the similarity of
being able to tell when their work is done, and quit before getting to the physical end of the table.
Index Types and Index Navigation
Although there are nominally two types of base index structures in SQL Server (clustered and non-clustered),
there are actually, internally speaking, three different types:
❑ Clustered indexes
Chapter 9: SQL Server Storage and Index Structures
❑ Non-clustered indexes, which comprise:
❑ Non-clustered indexes on a heap
❑ Non-clustered indexes on a clustered index
269