SQL Server Team-based Development - Red Gate Software

327
Chapter 11: SQL Refactoring
Random I/O access when filtering on non-clustered indexes
Unless you adopt a particularly reckless approach to indexing, it's highly unlikely that
every column in a table will be covered by an index. If you use SELECT * in a query, and
so return columns that aren't really required, you will probably end up doing a clustered
index scan, when it might well have been possible to perform an efficient index seek, if
only the necessary data been requested.
For clustered tables (i.e. tables with a clustered index), all data is stored in clustered
index leaf pages. Non-clustered indexes only contain the clustering key and the data for
columns on which the index is defined. These columns can be retuned via an index seek
operation, but if a query requests any additional columns then the data is looked up in the
clustered index. This lookup has had different names in last few years, such as "bookmark
lookup" or "KEY lookup." It is a random access I/O operation, which is very expensive.
INCLUDED columns
SQL Server 2005 introduced a feature called INCLUDED columns by which we can include extra columns
in the leaf level of a non-clustered index. For more information, refer to Books Online.
If your use of SELECT * forces bookmark lookups, as it inevitably will, then the optimizer
may quickly decide to abandon the "index seek + book markup lookup" route in
favor of a full index scan. The reason is that an index scan is a sequential I/O operation,
and can be more optimal than performing a moderate number of random I/O operations,
even if the former ends up reading much more data.
The threshold at which this switch is made will vary from system to system, so you
should run tests on your system. Listing 11-8 shows the code explaining the problem
with bookmark lookups, when using SELECT *.