SQL Server Execution Plans - Red Gate Software

Chapter 2: Graphical Execution Plans for Basic Queries
properties about the index that can be useful in understanding how the operator works
and what it is doing. Some of the properties are self-explanatory, but others might bear
some information. The Estimated I/O Cost and Estimated CPU Cost are measures
assigned by the optimizer, and each operator's cost contributes to the overall cost of the
plan. I'll detail various points on these properties and others that are interesting for each
execution plan as we hit that plan and that operator. Not all the operators will be useful
in figuring out each execution plan. For example, rebinds and rewinds are only important
when dealing with Nested Loops joins, but there are none of those in this plan, so those
values are useless to you.
Indexes in SQL Server are stored in a balanced-tree, or a b-tree (a series of nodes that
point to a parent). A clustered index not only stores the key structure, like a regular index,
but also sorts and stores the data at the lowest level of the index, known as the leaf,
which is the reason why there can be only one clustered index per table. This means that
a Clustered Index Scan is very similar in concept to a Table Scan. The entire index, or a
large percentage of it, is being traversed, row by row, in order to retrieve the data needed
by the query.
An Index Scan often occurs, as in this case, when an index exists but the optimizer determines
that there are so many rows to return that it is quicker to simply scan all the values
in the index rather than use the keys provided by that index. In other situations, a scan is
necessary because the index is not selective enough for the optimizer to be sure of finding
the values it needs without scanning a large percentage of the index. That can also occur
when the statistics for that index are out of date and showing incorrect information. You
can also have situations where a query applies functions to columns, which means the
optimizer can't determine what the value for that column could be so it has to scan the
entire index to find it.
An obvious question to ask, if you see an Index Scan in your execution plan, is whether
you are returning more rows than is necessary. If the number of rows returned is higher
than you expect, that's a strong indication that you need to fine-tune the WHERE clause
of your query so that only those rows that are actually needed are returned. Returning
unnecessary rows wastes SQL Server resources and hurts overall performance.
67