You’re probably most familiar with
the terms ‘Seek’ and ‘Scan’ from
the graphical plans produced by SQL Server Management Studio (SSMS).
The image to
the left shows
the most common ones, with
the three types of scan at
the top, followed by four types of seek. You might look to
the SSMS tool-tip descriptions to explain
the differences between them: Not hugely helpful are they? Both mention scans and ranges (nothing about seeks) and
the Index Seek description implies that it will not scan
the index entirely (which isn’t necessarily true). Recall also yesterday’s post where we saw two Clustered Index Seek operations doing very different things.
The first Seek performed 63 single-row seeking operations; and
the second performed a ‘Range Scan’ (more on those later in this post). I hope you agree that those were two very different operations, and perhaps you are wondering why there aren’t different graphical plan icons for Range Scans and Seeks? I have often wondered about that, and
the first person to mention it after yesterday’s post was Erin Stellato (twitter | blog): Before we go on to make sense of all this, let’s look at another example of how SQL Server confusingly mixes
the terms ‘Scan’ and ‘Seek’ in different contexts.
The diagram below shows a very simple heap table with two columns, one of which is
the non-clustered Primary Key, and
the other has a non-unique non-clustered index defined on it.
The right hand side of
the diagram shows a simple query, it’s associated query plan, and a couple of extracts from
the SSMS tool-tip and Properties windows. Notice
the ‘scan direction’ entry in
the Properties window snippet. Is this a seek or a scan?
The different references to Scans and Seeks are even more pronounced in
the XML plan output that
the graphical plan is based on. This fragment is what lies behind
the single Index Seek icon shown above: You’ll find
the same confusing references to Seeks and Scans throughout
the product and its documentation. Making Sense of Seeks Let’s forget all about scans for a moment, and think purely about seeks. Loosely speaking, a seek is
the process of navigating an index B-tree to find a particular index record, most often at
the leaf level. A seek starts at
the root and navigates down through
the levels of
the index to find
the point of interest: Singleton Lookups
The simplest sort of seek predicate performs this traversal to find (at most) a single record. This is
the case when we search for a single value using a unique index and an equality predicate. It should be readily apparent that this type of search will either find one record, or none at all. This operation is known as a singleton lookup. Given
the example table from before,
the following query is an example of a singleton lookup seek: Sadly, there’s nothing in
the graphical plan or XML output to show that this is a singleton lookup – you have to infer it from
the fact that this is a single-value equality seek on a unique index.
The other common examples of a singleton lookup are bookmark lookups – both
the RID and Key Lookup forms are singleton lookups (an RID lookup finds a single record in a heap from
the unique row locator, and a Key Lookup does much
the same thing on a clustered table). If you happen to run your query with STATISTICS IO ON, you will notice that ‘Scan Count’ is always zero for a singleton lookup. Range Scans
The other type of seek predicate is a ‘seek plus range scan’, which I will refer to simply as a range scan.
The seek operation makes an initial descent into
the index structure to find
the first leaf row that qualifies, and then performs a range scan (either backwards or forwards in
the index) until it reaches
the end of
the scan range.
The ability of a range scan to proceed in either direction comes about because index pages at
the same level are connected by a doubly-linked list – each page has a pointer to
the previous page (in logical key order) as well as a pointer to
the following page.
The doubly-linked list is represented by
the green and red dotted arrows in
the index diagram presented earlier. One subtle (but important) point is that
the notion of a ‘forward’ or ‘backward’ scan applies to
the logical key order defined when
the index was built. In
the present case,
the non-clustered primary key index was created as follows: CREATE TABLE
dbo.Example
(
key_col INTEGER NOT NULL,
data INTEGER NOT NULL,
CONSTRAINT [PK dbo.Example key_col]
PRIMARY KEY NONCLUSTERED (key_col ASC)
)
;
Notice that
the primary key index specifies an ascending sort order for
the single key column. This means that a forward scan of
the index will retrieve keys in ascending order, while a backward scan would retrieve keys in descending key order. If
the index had been created instead on key_col DESC, a forward scan would retrieve keys in descending order, and a backward scan would return keys in ascending order.
A range scan seek predicate may have a Start condition, an End condition, or both. Where one is missing,
the scan starts (or ends) at one extreme end of
the index, depending on
the scan direction. Some examples might help clarify that:
the following diagram shows four queries, each of which performs a single seek against a column holding every integer from 1 to 100 inclusive.
The results from each query are shown in
the blue columns, and relevant attributes from
the Properties window appear on
the right:
Query 1 specifies that all key_col values less than 5 should be returned in ascending order.
The query plan achieves this by seeking to
the start of
the index leaf (there is no explicit starting value) and scanning forward until
the End condition (key_col < 5) is no longer satisfied (SQL Server knows it can stop looking as soon as it finds a key_col value that isn’t less than 5 because all later index entries are guaranteed to sort higher).
Query 2 asks for key_col values greater than 95, in descending order. SQL Server returns these results by seeking to
the end of
the index, and scanning backwards (in descending key order) until it comes across a row that isn’t greater than 95. Sharp-eyed readers may notice that
the end-of-scan condition is shown as a Start range value. This is a bug in
the XML show plan which bubbles up to
the Properties window – when a backward scan is performed,
the roles of
the Start and End values are reversed, but
the plan does not reflect that. Oh well.
Query 3 looks for key_col values that are greater than or equal to 10, and less than 15, in ascending order. This time, SQL Server seeks to
the first index record that matches
the Start condition (key_col >= 10) and then scans forward through
the leaf pages until
the End condition (key_col < 15) is no longer met.
Query 4 performs much
the same sort of operation as Query 3, but requests
the output in descending order. Again, we have to mentally reverse
the Start and End conditions because of
the bug, but otherwise
the process is
the same as always: SQL Server finds
the highest-sorting record that meets
the condition ‘key_col < 25’ and scans backward until ‘key_col >= 20’ is no longer true.
One final point to note: seek operations always have
the Ordered: True attribute. This means that
the operator always produces rows in a sorted order, either ascending or descending depending on how
the index was defined, and whether
the scan part of
the operation is forward or backward. You cannot rely on this sort order in your queries of course (you must always specify an ORDER BY clause if order is important) but SQL Server can make use of
the sort order internally. In
the four queries
above,
the query optimizer was able to avoid an explicit Sort operator to honour
the ORDER BY clause, for example.
Multiple Seek Predicates
As we saw yesterday, a single index seek plan operator can contain one or more seek predicates. These seek predicates can either be all singleton seeks or all range scans – SQL Server does not mix them. For example, you might expect
the following query to contain two seek predicates, a singleton seek to find
the single record in
the unique index where key_col = 10, and a range scan to find
the key_col values between 15 and 20:
SELECT key_col
FROM dbo.Example
WHERE key_col = 10
OR key_col BETWEEN 15 AND 20
ORDER BY key_col ASC
;
In fact, SQL Server transforms
the singleton seek (key_col = 10) to
the equivalent range scan, Start:[key_col >= 10], End:[key_col <= 10]. This allows both range scans to be evaluated by a single seek operator. To be clear, this query results in two range scans: one from 10 to 10, and one from 15 to 20.
Final Thoughts
That’s it for today – tomorrow we’ll look at monitoring singleton lookups and range scans, and I’ll show you a seek on a heap table.
Yes, a seek. On a heap. Not an index!
If you would like to run
the queries in this post for yourself, there’s a script below. Thanks for reading!
IF OBJECT_ID(N'dbo.Example', N'U')
IS NOT NULL
BEGIN
DROP TABLE dbo.Example;
END
;
-- Test table is a heap
-- Non-clustered primary key on 'key_col'
CREATE TABLE
dbo.Example
(
key_col INTEGER NOT NULL,
data INTEGER NOT NULL,
CONSTRAINT [PK dbo.Example key_col]
PRIMARY KEY NONCLUSTERED (key_col)
)
;
-- Non-unique non-clustered index on
the 'data' column
CREATE NONCLUSTERED INDEX
[IX dbo.Example data]
ON dbo.Example (data)
;
-- Add 100 rows
INSERT dbo.Example
WITH (TABLOCKX)
(
key_col,
data
)
SELECT key_col = V.number,
data = V.number
FROM master.dbo.spt_values AS V
WHERE V.[type] = N'P'
AND V.number BETWEEN 1 AND 100
;
-- ================
-- Singleton lookup
-- ================
;
-- Single value equality seek in a unique index
-- Scan count = 0 when STATISTIS IO is ON
-- Check
the XML SHOWPLAN
SELECT E.key_col
FROM dbo.Example AS E
WHERE E.key_col = 32
;
-- ===========
-- Range Scans
-- ===========
;
-- Query 1
SELECT E.key_col
FROM dbo.Example AS E
WHERE E.key_col <= 5
ORDER BY
E.key_col ASC
;
-- Query 2
SELECT E.key_col
FROM dbo.Example AS E
WHERE E.key_col > 95
ORDER BY
E.key_col DESC
;
-- Query 3
SELECT E.key_col
FROM dbo.Example AS E
WHERE E.key_col >= 10
AND E.key_col < 15
ORDER BY
E.key_col ASC
;
-- Query 4
SELECT E.key_col
FROM dbo.Example AS E
WHERE E.key_col >= 20
AND E.key_col < 25
ORDER BY
E.key_col DESC
;
-- Final query (singleton + range = 2 range scans)
SELECT E.key_col
FROM dbo.Example AS E
WHERE E.key_col = 10
OR E.key_col BETWEEN 15 AND 20
ORDER BY
E.key_col ASC
;
-- === TIDY UP ===
DROP TABLE dbo.Example;
© 2011 Paul White
email:
[email protected]
twitter: @SQL_Kiwi
