Covering nonmatching index scans

When the columns specified in the where clause do not include the leading column in the index, but all columns named in the select list and other query clauses (such as group by or having) are included in the index, Adaptive Server saves I/O by scanning the entire leaf level of the index, rather than scanning the table.

It cannot perform a matching scan because the first column of the index is not specified.

The query in Figure 5-12 shows a nonmatching index scan. This query does not use the leading columns on the index, but all columns required in the query are in the nonclustered index on lname, fname, emp_id.

The nonmatching scan must examine all rows on the leaf level. It scans all leaf level index pages, starting from the first page. It has no way of knowing how many rows might match the query conditions, so it must examine every row in the index. Since it must begin at the first page of the leaf level, it can use the pointer in syspartitions.firstpage rather than descend the index.

Figure 5-12: A nonmatching index scan

Image showing a series of pages from the root page on the left to the data pages on the right. The select scan reads all the pages at the leaf level. But the scan uses the information in sysindexes.firstpage instead of the root page to start the scan.