Craig Freedman's SQL Server Blog : Scans and Seeks

What is the difference between sys.dm_db_index_usage_stats and sys.dm_db_index_operational_stats?

craigfr — Fri, 31 Oct 2008 00:40:00 GMT

SQL Server includes two DMVs - sys.dm_db_index_usage_stats and sys.dm_db_index_operational_stats - that are extremely useful for monitoring which indexes are used as well as how and when they are used. Both DMVs report similar statistics on information such as the number of scans, seeks, and updates to different indexes. These DMVs are documented in Books Online (see here and here) and a simple Web search reveals numerous other postings about these DMVs. However, in my own search, I did not find many direct explanations of the difference between these two valuable DMVs. (You will find a short explanation halfway through this post on the Microsoft SQL Server Customer Advisory Team blog.)

The main difference between these DMVs is simple but important:

sys.dm_db_index_usage_stats records how many times the query optimizer uses an index in a plan. This usage information is recorded again each time the plan is executed. (Compiling a plan alone is not sufficient to record an index's usage.) However, and this is the important part, for the purposes of computing the statistics, it does matter how many times the query processor executes the specific operator that references the index. For that matter, it does not matter whether the query processor executes the operator at all. Mere execution of the plan counts as a single usage for each index used by the plan.

sys.dm_db_index_operational_stats records how many times the storage engine executes a specific operation on the index. These statistics do depend on how many times the query processor executes each operator. If an operator is never executed, the storage engine does not perform any operations on the index and the DMV reports that the index was not used. If an operator is executed multiple times, the storage engine performs multiple operations on the index and the DMV reports that the index was used multiple times.

Update (7/29/2009): The following paragraph is incorrect. See this post for more information.

(Another less important difference between these DMVs is that sys.dm_db_index_usage_stats only reports on indexes that have been used at least once since the server was last restarted while sys.dm_db_index_operational_stats reports on all indexes regardless of whether they have been used.)

Let's try an example to see this difference in action. I'll use the following simple schema:

CREATE TABLE T (A INT, B INT, C INT)
CREATE UNIQUE CLUSTERED INDEX TA ON T(A)
CREATE UNIQUE INDEX TB ON T(B)

As expected, immediately after creating this table, the stats are zero (or just non-existent):

SELECT index_id, user_seeks, user_scans, user_lookups, user_updates
FROM sys.dm_db_index_usage_stats
WHERE database_id = DB_ID('tempdb') and object_id = OBJECT_ID('tempdb..t')
ORDER BY index_id

SELECT index_id, range_scan_count, singleton_lookup_count
FROM sys.dm_db_index_operational_stats (DB_ID('tempdb'), OBJECT_ID('tempdb..t'), NULL, NULL)
ORDER BY index_id

index_id    user_seeks           user_scans           user_lookups         user_updates
----------- -------------------- -------------------- -------------------- --------------------

index_id    range_scan_count     singleton_lookup_count
----------- -------------------- ----------------------
1           0                    0
2           0                    0

Now suppose that we do a scan of the clustered index:

SELECT * FROM T

|--Clustered Index Scan(OBJECT:([tempdb].[dbo].[T].[TA]))

Repeating the DMV queries, we see that the clustered index shows one scan in both DMVs. SQL Server records the scan even though the table contains no rows and the query returns an empty result:

index_id    user_seeks           user_scans           user_lookups         user_updates
----------- -------------------- -------------------- -------------------- --------------------
1           0                    1                    0                    0

index_id    range_scan_count     singleton_lookup_count
----------- -------------------- ----------------------
1           1                    0
2           0                    0

Next let's try a singleton lookup on the clustered index:

SELECT * FROM T WHERE A = 1

|--Clustered Index Seek(OBJECT:([tempdb].[dbo].[T].[TA]), SEEK:([tempdb].[dbo].[T].[A]=CONVERT_IMPLICIT(int,[@1],0)) ORDERED FORWARD)

Again the table contains no rows and the query returns an empty result. Nevertheless, the DMVs now report one seek and one singleton lookup:

index_id    user_seeks           user_scans           user_lookups         user_updates
----------- -------------------- -------------------- -------------------- --------------------
1           1                    1                    0                    0

index_id    range_scan_count     singleton_lookup_count
----------- -------------------- ----------------------
1           1                    1
2           0                    0

(Keep in mind that the DMV results are cumulative so you need to subtract the previous values from the current values as you run each of these experiments. Thus, we can disregard the scan that was already reported by the previous example.)

Now let's try something a little more interesting. Let's run a bookmark lookup:

SELECT * FROM T WHERE B = 1

|--Nested Loops(Inner Join, OUTER REFERENCES:([tempdb].[dbo].[T].[A]))
|--Index Seek(OBJECT:([tempdb].[dbo].[T].[TB]), SEEK:([tempdb].[dbo].[T].[B]=CONVERT_IMPLICIT(int,[@1],0)) ORDERED FORWARD)
|--Clustered Index Seek(OBJECT:([tempdb].[dbo].[T].[TA]), SEEK:([tempdb].[dbo].[T].[A]=[tempdb].[dbo].[T].[A]) LOOKUP ORDERED FORWARD)

As expected sys.dm_db_index_usage_stats reports a seek on index TB (index id 2) and a bookmark lookup on the clustered index (index id 1). However, sys.dm_db_index_operational_stats reports only the singleton lookup on index TB but does not report any new activity on the clustered index:

index_id    user_seeks           user_scans           user_lookups         user_updates
----------- -------------------- -------------------- -------------------- --------------------
1           1                    1                    1                    0
2           1                    0                    0                    0

index_id    range_scan_count     singleton_lookup_count
----------- -------------------- ----------------------
1           1                    1
2           0                    1

To understand what has happened, recall how a nested loops join works. The server executes the seek (the singleton lookup) on index TB and, as in the previous example, both DMVs are updated even though the seek returns no rows. However, since the seek on index TB returns no rows, the nested loops join does not execute the clustered index seek (i.e., the bookmark lookup). The server updates sys.dm_db_index_usage_stats to indicate that it executed a query plan that includes a bookmark lookup on table T, but does not update sys.dm_db_index_operational_stats since the query did not actually perform any bookmark lookups.

Next, let's insert three rows into the table and run another bookmark lookup experiment. I'm using a hint to force a bookmark lookup plan. Without the hint, the optimizer would simply use a clustered index scan since the query returns all three rows in the table:

INSERT T VALUES (0, 0, 0), (1, 1, 1), (2, 2, 2)
SELECT * FROM T WITH (INDEX (TB))

|--Nested Loops(Inner Join, OUTER REFERENCES:([tempdb].[dbo].[T].[A]))
|--Index Scan(OBJECT:([tempdb].[dbo].[T].[TB]))
|--Clustered Index Seek(OBJECT:([tempdb].[dbo].[T].[TA]), SEEK:([tempdb].[dbo].[T].[A]=[tempdb].[dbo].[T].[A]) LOOKUP ORDERED FORWARD)

This time sys.dm_db_index_usage_stats reports a scan on index TB and a bookmark lookup on the clustered index (plus the updates from the insert statement). But, sys.dm_db_index_operational_stats reports a scan on index TB and three bookmark lookups on the clustered index:

index_id    user_seeks           user_scans           user_lookups         user_updates
----------- -------------------- -------------------- -------------------- --------------------
1           1                    1                    2                    1
2           1                    1                    0                    1

index_id    range_scan_count     singleton_lookup_count
----------- -------------------- ----------------------
1           1                    4
2           1                    1

When the server executes the above query, it runs the clustered index seek three times - once for each row returned by the index scan. We ran the query only once but it performed three bookmark lookups. Thus, as in the prior example, the server updates sys.dm_db_index_usage_stats to indicate that it executed a query plan that includes a bookmark lookup on table T, but unlike the prior example, it updates sys.dm_db_index_operational_stats to indicate that the query performed three actual bookmark lookups.

I've used bookmark lookups in the above examples, but any nested loops join will produce similar results. At this point, it should be clear that the statistics returned by these two DMVs can differ dramatically.

So, what is the important takeaway from all of these examples? Don't expect the data reported by these two DMVs to match. sys.dm_db_index_usage_stats tells us the proportion of query plans that were executed that use various indexes. This information is useful for concluding how many of the executed query plans might be affected if we drop an index but it does not tell us how many actual operations are performed using each index. sys.dm_db_index_operational_stats, on the other hand, tells us how often the indexes are actually used during the execution of plans and, thus, which indexes are directly contributing to server performance. But, even if sys.dm_db_index_operational_stats indicates that an index is not used very often (or perhaps even that an index is never used), do not automatically conclude that you can drop the index. First, be sure that sys.dm_db_index_usage_stats indicates that no queries depend on the index. In some cases, the presence of an index could change a query plan for the better even though the index itself is not used when the plan is executed.

Sequential Read Ahead

craigfr — Tue, 23 Sep 2008 23:45:00 GMT

Balancing CPU and I/O throughput is essential to achieve good overall performance and to maximize hardware utilization. SQL Server includes two asynchronous I/O mechanisms - sequential read ahead and random prefetching - that are designed to address this challenge.

To understand why asynchronous I/O is so important, consider the CPU to I/O performance gap. The memory subsystem on a modern CPU can deliver data sequentially at roughly 5 Gbytes per second per socket (or for non-NUMA machines for all sockets sharing the same bus) and (depending on how you measure it) can fetch random memory locations at roughly 10 to 50 million accesses per second. By comparison, a high end 15K SAS hard drive can read only 125 Mbytes per second sequentially and can perform only 200 random I/Os per second (IOPS). Solid State Disks (SSDS) can reduce the gap between sequential and random I/O performance by eliminating the moving parts from the equation, but a performance gap remains. In an effort to close this performance gap, it is not uncommon for servers to have a ratio of 10 or more drives for every CPU. (It is also important to consider and balance the entire I/O subsystem including the number and type of disk controllers not just the drives themselves but that is not the focus of this post.)

Unfortunately, a single CPU issuing only synchronous I/Os can keep only one spindle active at a time. For a single CPU to exploit the available bandwidth and IOPs of multiple spindles effectively the server must issue multiple I/Os asynchronously. Thus, SQL Server includes the aforementioned read ahead and prefetching mechanisms. In this post, I'll take a look at sequential read ahead.

When SQL Server performs a sequential scan of a large table, the storage engine initiates the read ahead mechanism to ensure that pages are in memory and ready to scan before they are needed by the query processor. The read ahead mechanism tries to stay 500 pages ahead of the scan. We can see the read ahead mechanism in action by checking the output of SET STATISTICS IO ON. For example, I ran the following query on a 1GB scale factor TPC-H database. The LINEITEM table has roughly 6 million rows.

SET STATISTICS IO ON

SELECT COUNT(*) FROM LINEITEM

Table 'LINEITEM'. Scan count 3, logical reads 22328, physical reads 3, read-ahead reads 20331, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Repeating the query a second time shows that the table is now cached in the buffer pool:

SELECT COUNT(*) FROM LINEITEM

Table 'LINEITEM'. Scan count 3, logical reads 22328, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

For sequential I/O performance, it is important to distinguish between allocation ordered and index ordered scans. An allocation ordered scan tries to read pages in the order in which they are physically stored on disk while an index ordered scan reads pages according to the order in which the data on those index pages is sorted. (Note that in many cases there are multiple levels of indirection such as RAID devices or SANS between the logical volumes that SQL Server sees and the physical disks. Thus, even an allocation ordered scan may in fact not be truly optimally ordered.) Although SQL Server tries to sort and read pages in allocation order even for an index ordered scan, an allocation ordered scan is generally going to be faster since pages are read in the order that they are written on disk with the minimal number of seeks. Heaps have no inherent order and, thus, are always scanned in allocation order. Indexes are scanned in allocation order only if the isolation level is read uncommitted (or the NOLOCK hint is used) and only if the query process does not request an ordered scan. Defragmenting indexes can help to ensure that index ordered scans perform on par with allocation ordered scans.

In my next post, I'll take a look at random prefetching.

Partitioned Indexes in SQL Server 2008

craigfr — Tue, 05 Aug 2008 21:33:00 GMT

In my last post, I looked at how SQL Server 2008 handles scans on partitioned tables. I explained that SQL Server 2008 treats partitioned tables as tables with a logical index on the partition id column and that SQL Server 2008 implements partition elimination by performing a logical index seek on the partition id column. Specifically, I showed some examples using a heap. In this post, I'll continue this discussion and explore how SQL Server 2008 handles scans and seek on partitioned indexes.

Let's begin with a simple example:

CREATE PARTITION FUNCTION PF(INT) AS RANGE FOR VALUES (0, 10, 100)
CREATE PARTITION SCHEME PS AS PARTITION PF ALL TO ([PRIMARY])

CREATE TABLE T1 (A INT, B INT)
CREATE CLUSTERED INDEX T1A ON T1(A) ON PS(A)

As I noted in my last post, the SQL Server query processor logically treats this partitioned index as a multi-column index on ([PtnId], A). We can scan this logical index just like any real index:

SELECT * FROM T1

|--Clustered Index Scan(OBJECT:([T1].[T1A]))

This query uses the same plan as any other clustered index scan. It implicitly scans all of the partitions. Aside from the "Partitioned" attribute in the graphical and XML plans, there is no difference between this plan and a similar clustered index scan on a non-partitioned table. We can also perform a seek on the logical index:

DECLARE @I INT
SELECT @I = 0
SELECT * FROM T1 WHERE A = @I

|--Clustered Index Seek(OBJECT:([T1].[T1A]), SEEK:([PtnId1000]=RangePartitionNew([@I],(0),(0),(10),(100)) AND [T1].[A]=[@I]) ORDERED FORWARD)

Notice that SQL Server derives the predicate on the [PtnId] column from the explicit predicate on column A. SQL Server then seeks on both columns of the logical index - [PtnId] and column A - just as if the logical index were a real index. So far, everything is pretty straightforward. Now, let's consider a slightly more complex scenario:

DECLARE @I INT
SELECT @I = 0
SELECT * FROM T1 WHERE A < @I

Both this and the prior example have predicates on column A. In both cases, SQL Server derives a predicate on the [PtnId] column. However, in the prior example, the derived predicate was an equality predicate that limited the seek to a single partition. In this example, due to the inequality, the derived predicate is actually a range of partitions:

|--Clustered Index Seek(OBJECT:([T1].[T1A]), SEEK:([PtnId1000] >= (1) AND [PtnId1000] <= RangePartitionNew([@I],(0),(0),(10),(100)) AND [T1].[A] < [@I]) ORDERED FORWARD)

If you are familiar with the rules on index seeks, you will notice something odd about this plan. Ordinarily, SQL Server can only perform an index seek on the second column of a multi-column index if there exists an equality predicate on the first column. Clearly, there is not an equality predicate on the [PtnId] column in this query and yet there is a predicate on column A. What's going on? The query processor supports a special type of index seek on partitioned tables. Basically, the query processor first uses the predicate on the [PtnId] column to identify those partitions into which to seek and then seeks again using the predicate on column A. Because the seek operator skips over some rows in each partition that do not match the predicate on column A, we refer to this type of seek as a skip scan. Note that this operation really is a seek - it is not a residual predicate. The storage engine only returns those rows that pass both predicates. Also note that SQL Server 2008 only supports this skip scan functionality on the [PtnId] column of a partitioned table.

Now let's change the schema slightly:

CREATE TABLE T2 (A INT, B INT)
CREATE CLUSTERED INDEX T2A ON T2(A) ON PS(B)

This new table is indexed on column A but partitioned on column B. Once again, SQL Server logically treats the index as a multi-column index on ([PtnId], B).

DECLARE @I INT
SELECT @I = 0
SELECT * FROM T2 WHERE A = @I

Since the table is partitioned on column B, we cannot use the predicate on column A to derive a predicate on the [PtnId] column. Fortunately, the query processor can still perform a skip scan by adding a predicate on the [PtnId] column that explicitly scans all partitions:

|--Clustered Index Seek(OBJECT:([T2].[T2A]), SEEK:([PtnId1000] >= (1) AND [PtnId1000] <= (4) AND [T2].[A]=[@I]) ORDERED FORWARD)

Finally, before I wrap up this post, I'd like to point out that, while it's not often useful, we can add an explicit predicate on the [PtnId] column of a table. To do so, we use the $PARTITION function:

DECLARE @PtnId INT
SELECT @PtnId = 1
SELECT * FROM T1 WHERE $PARTITION.PF(A) = @PtnId

|--Clustered Index Scan(OBJECT:([T1].[T1A]), SEEK:([PtnId1000]=[@PtnId]) ORDERED FORWARD)

Just as with the derived [PtnId] predicates, SQL Server can perform a seek on the [PtnId] column. When using this syntax, it is important to use the correct $PARTITION function and the correct column or SQL Server will not recognize it as the [PtnId] column for this table.

Books Online has more information on these and other partitioned table changes in SQL Server 2008.

Partitioned Tables in SQL Server 2008

craigfr — Wed, 16 Jul 2008 00:03:00 GMT

In this post, I introduced how SQL Server 2005 implements query plans on partitioned tables. If you've read that post or used partitioned tables, you may recall that SQL Server 2005 uses a constant scan operator to enumerate the list of partition ids that need to be scanned. As a refresher, here is the example from that post showing the plan for scanning a table with four partitions:

CREATE PARTITION FUNCTION PF(INT) AS RANGE FOR VALUES (0, 10, 100)
CREATE PARTITION SCHEME PS AS PARTITION PF ALL TO ([PRIMARY])
CREATE TABLE T (A INT, B INT) ON PS(A)

SELECT * FROM T

|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1004]) PARTITION ID:([PtnIds1004]))
|--Constant Scan(VALUES:(((1)),((2)),((3)),((4))))
|--Table Scan(OBJECT:([t]))

SQL Server 2005 treats partitioned tables specially and creates special plans, such as the above one, for partitioned tables. SQL Server 2008, on the other hand, for the most part treats partitioned tables as regular tables that just happen to be logically indexed on the partition id column. For example, for the purposes or query optimization and query execution, SQL Server 2008 treats the above table not as a heap but as an index on [PtnId]. If we create a partitioned index (clustered or non-clustered), SQL Server 2008 logically adds the partition id column as the first column of the index. For instance, if we create the following index:

CREATE INDEX TA ON T(A) ON PS(A)

SQL Server 2008 treats it not as a single column index on T(A), but rather as a multi-column or composite index on T([PtnId],A). Note that the table and index are still stored physically as partitioned tables. In this example, the table and non-clustered index are decomposed into four heaps and four non-clustered indexes.

By treating partitioned tables as indexes, SQL Server 2008 can frequently use much simpler query plans. Let's look at the SQL Server 2008 plan for the above example:

|--Table Scan(OBJECT:([T]))

This query plan is no different than what you might see if you scanned any other ordinary table! So, how can we tell that the table is really partitioned and how can we tell what partitions the plan is going to scan? Luckily, the graphical and XML plans identify partitioned tables by adding a "Partitioned" attribute to any scan, seek, or update operator that processes a partitioned table. Moreover, the actual graphical plan and the STATISTICS XML output identify the exact partitions that the plan touches during execution. For example, here is an excerpt from the STATISTICS XML output generated by running the above query:

<RunTimePartitionSummary>
<PartitionsAccessed PartitionCount="4">
<PartitionRange Start="1" End="4"/>
</PartitionsAccessed>
</RunTimePartitionSummary>

This output shows that, as expected, the query plan scanned all four partitions of the table. Now, suppose we insert a row into the second partition (up until now, the table has been empty) and run the following slightly modified query:

INSERT T VALUES (1, 1)

SELECT TOP 1 * FROM T

This query can stop executing as soon as it finds a single row. It scans the first partition and finding no rows continues on to scan the second partition. At that point, it finds a row and stops. Thus, the query terminates after scanning only two partitions. This outcome is clearly reflected in the STATISTICS XML output:

<RunTimePartitionSummary>
<PartitionsAccessed PartitionCount="2">
<PartitionRange Start="1" End="2"/>
</PartitionsAccessed>
</RunTimePartitionSummary>

Now let's see how partition elimination works. Let's start with static partition elimination:

SELECT * FROM T WHERE A < 100

|--Table Scan(OBJECT:([T]), SEEK:([PtnId1001] >= (1) AND [PtnId1001] <= (3)), WHERE:([T].[A]<(100)) ORDERED FORWARD)

Because SQL Server 2008 treats the partitioned table like an index on [PtnId], it can simply calculate the range of partitions that need to be scanned and perform a "seek" on those partitions. It may seem a little strange to see a SEEK predicate on a table scan, but it just means that the plan is going to scan partitions 1 through 3.

And now, let's look at dynamic partition elimination:

DECLARE @I INT
SELECT @I = 0
SELECT * FROM T WHERE A < @I

|--Table Scan(OBJECT:([T]), SEEK:([PtnId1001] >= (1) AND [PtnId1001] <= RangePartitionNew([@I],(0),(0),(10),(100))), WHERE:([T].[A]<[@I]) ORDERED FORWARD)

This plan is identical to the prior plan except that the constant partition id 3 has been replaced by the RangePartitionNew function which computes the correct partition id from the variable @I. To find out exactly which partitions were scanned, we can once again check the STATISTICS XML output:

<RunTimePartitionSummary>
<PartitionsAccessed PartitionCount="1">
<PartitionRange Start="1" End="1"/>
</PartitionsAccessed>
</RunTimePartitionSummary>

Note that this plan computes exactly which partitions to scan. Compare that to the SQL Server 2005 plan which evaluates a filter for each and every partition id:

|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1004]) PARTITION ID:([PtnIds1004]))
       |--Filter(WHERE:([PtnIds1004]<=RangePartitionNew([@i],(0),(0),(10),(100))))
       |    |--Constant Scan(VALUES:(((1)),((2)),((3)),((4))))
       |--Table Scan(OBJECT:([t]), WHERE:([t].[a]<[@i]) PARTITION ID:([PtnIds1004]))

While evaluating the filter repeatedly may not cost too much if we have only four partitions, it is certainly going to waste some cycles if we have many partitions!

In my next post, I'll take a look at how SQL Server 2008 handles scans and seeks on partitioned indexes.

Query Processing Presentation

craigfr — Thu, 15 May 2008 19:39:00 GMT

Last week, I had the opportunity to talk to the New England SQL Server Users Group. I would like to thank the group for inviting me, Adam Machanic for organizing the event, and Red Gate for sponsoring it. My talk was an introduction to query processing, query execution, and query plans in SQL Server. I've had a request for the slides, so here they are. Enjoy!

Repeatable Read Isolation Level

craigfr — Wed, 09 May 2007 17:57:00 GMT

In my last two posts, I showed how queries running at read committed isolation level may generate unexpected results in the presence of concurrent updates. Many but not all of these results can be avoided by running at repeatable read isolation level. In this post, I'll explore how concurrent updates may affect queries running at repeatable read.

Unlike a read committed scan, a repeatable read scan retains locks on every row it touches until the end of the transaction. Even rows that do not qualify for the query result remain locked. These locks ensure that the rows touched by the query cannot be updated or deleted by a concurrent session until the current transaction completes (whether it is committed or rolled back). These locks do not protect rows that have not yet been scanned from updates or deletes and do not prevent the insertion of new rows amid the rows that are already locked. The following graphic illustrates this point:

Note that the capability to insert new "phantom" rows between locked rows that have already been scanned is the principle difference between the repeatable read and serializable isolation levels. A serializable scan acquires a key range lock which prevents the insertion of any new rows anywhere within the range (as well as the update or deletion of any existing rows within the range).

In the remainder of this post, I'll give a couple of examples of how we can get unexpected results even while running queries at repeatable read isolation level. These examples are similar to the ones from my previous two posts.

Row Movement

First, let's see how we can move a row and cause a repeatable read scan to miss it. As with all of the other example in this series of posts, we'll need two sessions. Begin by creating this simple table:

create table t (a int primary key, b int)
insert t values (1, 1)
insert t values (2, 2)
insert t values (3, 3)

Next, in session 1 lock the second row:

begin tran
update t set b = 2 where a = 2

Now, in session 2 run a repeatable read scan of the table:

select * from t with (repeatableread)

This scan reads the first row then blocks waiting for session 1 to release the lock it holds on the second row. While the scan is blocked, in session 1 let's move the third row to the beginning of the table before committing the transaction and releasing the exclusive lock blocking session 2:

update t set a = 0 where a = 3
commit tran

As we expect, session 2 completely misses the third row and returns just two rows:

a           b           c
----------- ----------- -----------
1           1           1
2           2           2

Note that if we change the experiment so that session 1 tries to touch the first row in the table, it will cause a deadlock with session 2 which holds a lock on this row.

Phantom Rows

Let's also take a look at how phantom rows can cause unexpected results. This experiment is similar to the nested loops join experiment from my previous post. Begin by creating two tables:

create table t1 (a1 int primary key, b1 int)
insert t1 values (1, 9)
insert t1 values (2, 9)

create table t2 (a2 int primary key, b2 int)

Now, in session 1 lock the second row of table t1:

begin tran
update t1 set a1 = 2 where a1 = 2

Next, in session 2 run the following outer join at repeatable read isolation level:

set transaction isolation level repeatable read
select * from t1 left outer join t2 on b1 = a2

The query plan for this join uses a nested loops join:

|--Nested Loops(Left Outer Join, WHERE:([t1].[b1]=[t2].[a2]))
|--Clustered Index Scan(OBJECT:([t1].[PK__t1]))
|--Clustered Index Scan(OBJECT:([t2].[PK__t2]))

This plan scans the first row from t1, tries to join it with t2, finds there are no matching rows, and outputs a null extended row. It then blocks waiting for session 1 to release the lock on the second row of t1. Finally, in session 1, insert a new row into t2 and release the lock:

insert t2 values (9, 0)
commit tran

Here is the output from the outer join:

a1          b1          a2          b2
----------- ----------- ----------- -----------
1           9           NULL        NULL
2           9           9           0

Notice that we have both a null extended and a joined row for the same join key!

Summary

As I pointed out at the conclusion of my previous post, I want to emphasize that the above results are not incorrect but rather are a side effect of running at a reduced isolation level. SQL Server guarantees that the committed data is consistent at all times.

CLARIFICATION 8/26/2008: The above examples work as I originally described if they are executed in tempdb. However, the SELECT statements in session 2 may not block as described if the examples are executed in other databases due to an optimization where SQL Server avoids acquiring read committed locks when it knows that no data has changed on a page. If you encounter this problem, either run these examples in tempdb or change the UPDATE statements in session 1 so that they actually change the data in the updated row. For instance, for the first example try "update t set b = 12 where a = 2".

Read Committed Isolation Level

craigfr — Wed, 25 Apr 2007 19:59:00 GMT

SQL Server 2000 supports four different isolation levels: read uncommitted (or nolock), read committed, repeatable read, and serializable. SQL Server 2005 adds two new isolation levels: read committed snapshot and snapshot. These isolation levels determine what locks SQL Server takes when accessing data and, therefore, by extension they determine the level of concurrency and consistency that statements and transactions experience. All of these isolation levels are described in Books Online.

In this post, I'm going to take a closer look at the default isolation level of read committed. When SQL Server executes a statement at the read committed isolation level, it acquires short lived share locks on a row by row basis. The duration of these share locks is just long enough to read and process each row; the server generally releases each lock before proceeding to the next row. Thus, if you run a simple select statement under read committed and check for locks (e.g., with sys.dm_tran_locks), you will typically see at most a single row lock at a time. The sole purpose of these locks is to ensure that the statement only reads and returns committed data. The locks work because updates always acquire an exclusive lock which blocks any readers trying to acquire a share lock.

Now, let's suppose that we scan an entire table at read committed isolation level. Since the scan locks only one row at a time, there is nothing to prevent a concurrent update from moving a row before or after our scan reaches it. The following graphic illustrates this point:

Let's try an experiment to see this effect in action. We'll need two server sessions for this experiment. First, create a simple table with three rows:

create table t (a int primary key, b int)
insert t values (1, 1)
insert t values (2, 2)
insert t values (3, 3)

Next, in session 1 lock the second row:

begin tran
update t set b = 2 where a = 2

Now, in session 2 run a simple scan of the table:

select * from t

This scan will read the first row and then block waiting for session 1 to release the lock it holds on the second row. While the scan is blocked, in session 1 we can swap the first and third rows and then commit the transaction and release the exclusive lock blocking session 2:

update t set a = 4 where a = 1
update t set a = 0 where a = 3
select * from t
commit tran

Here are the new contents of the table following these updates:

a           b
----------- -----------
0           3
2           2
4           1

Finally, here is the result of the scan from session 2:

a           b
----------- -----------
1          1
2           2
4           1

Notice that in this output the first row was scanned prior to the updates while the third row was scanned following the updates. In fact, these two rows are really the same row from before and after the update. Moreover, the original third row that had the value (3, 3) is not output at all. (We could claim that changing the primary key effectively deleted one row and created a new row, but we could also achieve the same effect on a non-clustered index.)

Finally, try repeating this experiment, but add a unique column to the table:

create table t (a int primary key, b int, c int unique)
insert t values (1, 1, 1)
insert t values (2, 2, 2)
insert t values (3, 3, 3)

You'll get the same result, but you'll see "duplicates" in the unique column.

If the above results are not acceptable, you can either enable read committed snapshot for your database or you can run at a higher isolation level (albeit with somewhat lower concurrency).

CLARIFICATION 8/26/2008: The above example works as I originally described if it is executed in tempdb. However, the SELECT statement in session 2 may not block as described if the example is executed in other databases due to an optimization where SQL Server avoids acquiring read committed locks when it knows that no data has changed on a page. If you encounter this problem, either run this example in tempdb or change the UPDATE statement in session 1 so that it actually changes the value of column b. For example, try "update t set b = 12 where a = 2".

Introduction to Partitioned Tables

craigfr — Mon, 27 Nov 2006 22:56:00 GMT

In this post, I’m going to take a look at how query plans involving partitioned tables work. Note that there is a big difference between partitioned tables (available only in SQL Server 2005) and partitioned views (available both in SQL Server 2000 and in SQL Server 2005). I will look at the query plans for partitioned views in a future post.

Table Scan

Let’s begin by creating a simple partitioned table:

create partition function pf(int) as range for values (0, 10, 100)

create partition scheme ps as partition pf all to ([primary])

create table t (a int, b int) on ps(a)

This creates a table with four partitions. SQL Server assigns sequential partition ids to each of the four partitions as follows:

PtnId	Values
1	t.a <= 0
2	0 < t.a <= 10
3	10 < t.a <= 100
4	100 < t.a

Now let’s examine the query plan for a simple table scan:

select * from t

|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1004]) PARTITION ID:([PtnIds1004]))
|--Constant Scan(VALUES:(((1)),((2)),((3)),((4))))
|--Table Scan(OBJECT:([t]))

SQL Server explicitly enumerates the partition ids that the table scan must touch using the constant scan and nested loops join operators. Recall that a nested loops join executes its second or inner input (in this case the table scan) once for each value from its first or outer input (in this case the constant scan). Thus, we run the table scan four times; once for each partition id.

Note also that the nested loops join explicitly identifies the partition id column as [PtnIds1004]. Although it is not immediately obvious from the text showplan (unfortunately, we omit this information in some though not all cases), the table scan uses the partition id column and checks it on each execution to determine which partition to scan. This information is always available in the graphical showplan (via the table scan tool tip and properties) and in the XML showplan:

...

</PartitionId>

</TableScan>

Static Partition Elimination

Consider the following query:

select * from t where a < 100

|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1005]) PARTITION ID:([PtnIds1005]))
|--Constant Scan(VALUES:(((1)),((2)),((3))))
|--Table Scan(OBJECT:([t]), WHERE:([t].[a]<(100)) PARTITION ID:([PtnIds1005]))

The predicate “a < 100” clearly eliminates all rows from partition id 4. There is no point in scanning this partition as none of the rows in this partition can possibly qualify for the predicate. The optimizer recognizes this fact and eliminates that partition from the plan. The constant scan now enumerates only three partitions. We refer to this as “static partition elimination” because we know the exact list of partitions to scan statically at compile time.

If we can statically eliminate all but one partition, we do not need the constant scan or join at all:

select * from t where a < 0

|--Table Scan(OBJECT:([t]), WHERE:([t].[a]<(0)) PARTITION ID:((1)))

Note that the exact partition id that we must scan (partition id 1) is now part of the table scan itself.

Dynamic Partition Elimination

In some cases, even though it is not possible for SQL Server to determine statically at compile time which partitions need to be scanned, the optimizer may be able to determine that some partition elimination is still possible.

declare @i int

select @i = 0

select * from t where a < @i

The above query is parameterized. Since we do not get the actual parameter value until run time (that I’ve provided a constant value for the parameter in the batch does not change things), there is no way to determine at compile time which partition ids to scan. We may scan just partition id 1, or we might scan partition ids 1 and 2, and so forth. Thus, the constant scan enumerates all four partition ids and we use a filter to eliminate partitions ids at run time. We refer to this as “dynamic partition elimination.”

The filter compares each partition id to the results of a special function “RangePartitionNew.” This function computes the results of applying the partition function to the parameter value. The arguments to this function (in left to right order) are: the value (in this case the parameter @i) that we want to map to a partition id, a Boolean flag that indicates whether the partition function maps boundary values to the left (0) or right (1), and the actual partition boundary values (in this case 0, 10, and 100).

In this example, since @i has the value 0, the result of RangePartitionNew is 1. Thus, we scan only partition id 1. Note that unlike the static partition elimination example, even though we scan only a single partition, we still have the constant scan and join. Again, we need these operators since we do not know how many partitions we will scan until run time.

In some cases, the optimizer can determine at compile time that we will scan only one partition even though it cannot determine which partition. For example, if we have an equality predicate on the partition key, we know that only partition can match. In this case, even though we have dynamic partition elimination, we do not need the constant scan and join. For example:

declare @i int

select @i = 0

select * from t where a = @i

|--Table Scan(OBJECT:([t]), WHERE:([t].[a]=[@i]) PARTITION ID:(RangePartitionNew([@i],(0),(0),(10),(100))))

Combining Static and Dynamic Partition Elimination

SQL Server can combine static and dynamic partition elimination in a single query plan:

declare @i int

select @i = 0

select * from t where a > 0 and a < @i

|--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1004]) PARTITION ID:([PtnIds1004]))
       |--Filter(WHERE:([PtnIds1004]<=RangePartitionNew([@i],(0),(0),(10),(100))))
       |    |--Constant Scan(VALUES:(((2)),((3)),((4))))
       |--Table Scan(OBJECT:([t]), WHERE:([t].[a]<[@i] AND [t].[a]>(0)) PARTITION ID:([PtnIds1004]))

Note that we statically eliminated partition id 1 from the constant scan and we may dynamically eliminate additional partition ids via a filter.

$partition

You can explicitly invoke the RangePartitionNew function using $partition:

select *, $partition.pf(a) from t

|--Compute Scalar(DEFINE:([Expr1004]=RangePartitionNew([t].[a],(0),(0),(10),(100))))
       |--Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1005]) PARTITION ID:([PtnIds1005]))
            |--Constant Scan(VALUES:(((1)),((2)),((3)),((4))))
            |--Table Scan(OBJECT:([t]))

This query plan is identical to the table scan plan above except that we compute and output the partition id for each row.

For More Information

This post from the SQL Server Development Customer Advisory Team blog includes more partition elimination examples. The post includes some examples of where partition elimination does not work if you have predicates with disjunctions and parameters (such as “a > 0 or a < @i”) and some workarounds. One of the workarounds is to use a “union all” statement to eliminate the disjunction. If you use this workaround, beware that you must be sure that the or’ed predicates will not overlap and return duplicates. In some cases, a duplicate eliminating union (be sure to include a unique key in the select list) may be safer.

Parallel Scan

craigfr — Thu, 02 Nov 2006 07:16:00 GMT

In this post, I’m going to take a look at how SQL Server parallelizes scans. The scan operator is one of the few operators that is parallel “aware.” Most operators neither need to know nor care whether they are executing in parallel; the scan is an exception.

How does parallel scan work?

The threads that compose a parallel scan work together to scan all of the rows in a table. There is no a-priori assignment or rows or pages to a particular thread. Instead, the storage engine dynamically hands out pages to threads. A parallel page supplier coordinates access to the pages of the table. The parallel page supplier ensures that each page is assigned to exactly one thread and, thus, is processed exactly once.

At the beginning of a parallel scan, each thread requests a set of pages from the parallel page supplier. The threads then begin processing these pages and returning rows. When a thread finishes with its assigned set of pages, it requests the next set of pages from the parallel page supplier.

This algorithm has a couple of advantages:

It is independent of the number of threads. We can add and remove threads from a parallel scan and it automatically adjusts. If we double the number of threads, each thread processes (approximately) half as many pages. And, if the I/O system can keep up, the scan runs twice as fast.
It is resilient to skew or load imbalances. If one thread runs slower than the other threads, that thread simply requests fewer pages while the other faster threads pick up the extra work. The total execution time degrades smoothly. (Compare this scenario to what would happen if we statically assigned pages to threads: the slow thread would dominate the total execution time.)

Example

Let’s begin with a simple example. To get a parallel plan, we’ll need a fairly big table; if the table is too small, the optimizer will conclude that a serial plan is perfectly adequate. The following script creates a table with 1,000,000 rows and (thanks to the fixed length char(200) column) about 27,000 pages. Warning: If you decide to run this example, it could a few minutes to populate this table.

create table T (a int, x char(200))

set nocount on

declare @i int

set @i = 0

while @i < 1000000

begin

insert T values(@i, @i)

set @i = @i + 1

end

Now, for the simplest possible query:

select * from T

|--Table Scan(OBJECT:([T]))

We get a serial plan! Why don’t we get a parallel plan? Parallelism is really about speeding up queries by applying more CPUs to the problem. The cost of this query is dominated by the cost of reading pages from disk (which is mitigated by read ahead rather than parallelism) and returning rows to the client. The query uses relatively few CPU cycles and, in fact, would probably run slower if we parallelized it.

If we add a fairly selective predicate to the query, we can get a parallel plan:

select * from T where a < 1000

|--Parallelism(Gather Streams)
|--Table Scan(OBJECT:([T]), WHERE:([T].[a]<CONVERT_IMPLICIT(int,[@1],0)))

By running this query in parallel, we can distribute the cost of evaluating this predicate across multiple CPUs. (In this case, the predicate is so cheap that it probably does not make much difference whether or not we run in parallel.)

Load Balancing

As I mentioned above, the parallel scan algorithm dynamically allocates pages to threads. We can see this in action. Consider this query which returns every row of the table:

select * from T where a % 2 = 0 or a % 2 = 1

The peculiar predicate confuses the optimizer which underestimates the cardinality and generates a parallel plan:

|--Parallelism(Gather Streams)
|--Table Scan(OBJECT:([T]), WHERE:([T].[a]%(2)=(0) OR [T].[a]%(2)=(1)))

On SQL Server 2005, using “SET STATISTICS XML ON” we can see exactly how many rows each thread processes. Here is an excerpt of the XML output on a two processor system:

</RunTimeInformation>

...

</RelOp>

We can see that both threads (threads 1 and 2) processed approximately half of the rows. (Thread 0 is the coordinator or main thread. It only executes the portion of the query plan above the topmost exchange. Thus, we do not expect it to process any rows for any parallel operators.)

Now let’s repeat the experiment, but let’s run an expensive serial query at the same time. This cross join query will run for a really long time (it needs to process one trillion rows) and use plenty of CPU cycles:

select min(T1.a + T2.a) from T T1 cross join T T2 option(maxdop 1)

This serial query will consume cycles from only one of the two CPUs. While it is running, let’s run the other query again:

select * from T where a % 2 = 0 or a % 2 = 1

</RunTimeInformation>

...

</RelOp>

This time thread 1 processed more than 90% of the rows while thread 2 which was busy executing the above serial plan processed far fewer rows. The parallel scan automatically balanced the work across the two threads. Since thread 1 had more free cycles (it wasn’t competing with the serial plan), it requested and scanned more pages.

If you try this experiment, don’t forget to kill the serial query when you are done! Otherwise, it will continue to run and waste cycles for a really long time.

The same load balancing that we just observed applies equally whether a thread is slowed down because of an external factor (such as the serial query in this example) or because of an internal factor. For example, if it costs more to process some rows than others, we will see the same behavior.

Index Union

craigfr — Wed, 18 Oct 2006 19:54:00 GMT

I was planning to continue writing about parallelism this week (and I will continue another time in another post), but I received an interesting question and chose to write about it instead.

Let’s begin by considering the following query:

create table T (a int, b int, c int, x char(200))

create unique clustered index Ta on T(a)

create index Tb on T(b)

create index Tc on T(c)

insert T values (1, 1, 1, 1)

insert T values (2, 2, 2, 2)

insert T values (3, 3, 3, 3)

select a from T where b = 1 or b = 3

|--Index Seek(OBJECT:([T].[Tb]), SEEK:([T].[b]=(1) OR [T].[b]=(3)) ORDERED FORWARD)

We have an index on column b and not surprisingly, the optimizer chooses to use the index and perform a seek. Since we have two predicates on column b, we get a seek with two predicates. First we execute the predicate “b = 1” and then we execute the predicate “b = 3”. Note that since we only output column a and since column a is the clustering key (and is, thus, covered by all non-clustered indexes), there is no need for a bookmark lookup. So far, there are no surprises.

Note that we could just as easily write this query as:

select a from T where b = 1

union all

select a from T where b = 3

|--Concatenation

|--Index Seek(OBJECT:([T].[Tb]), SEEK:([T].[b]=(1)) ORDERED FORWARD)

|--Index Seek(OBJECT:([T].[Tb]), SEEK:([T].[b]=(3)) ORDERED FORWARD)

The optimizer does not collapse the union all into a single index seek, but the queries and the plans are logically identical.

Now consider this query:

select a from T where b = 1 or c < 3

|--Clustered Index Scan(OBJECT:([T].[Ta]), WHERE:([T].[b]=(1) OR [T].[c]<(3)))

We have an index on both columns b and c, but we didn’t use either. Why not? We need all rows that satisfy either predicate. We could use the index on column b to get rows that satisfy the predicate “b = 1”, but we may miss rows that satisfy “c < 3” but for which “b != 1”. For example, we would miss the row with the value (2, 2, 2, 2). The same problem would occur if we use the index on column c to satisfy the predicate “c < 3”. (My sample data does not include a row with “b = 1” for which “c >= 3” but such a row could exist and so we must assume one does.)

Index union

So, is there a way for SQL Server to evaluate this query and use the indexes? Yes! First, for the optimizer to choose a plan other than the clustered index scan, we need to add enough data to the table to make the scan more expensive. (Note that I added a char(200) column to the original table to make the rows larger. This column makes the table occupy more pages which also makes the scan more expensive.)

truncate table T

set nocount on

declare @i int

set @i = 0

while @i < 1000

begin

insert T values(@i, @i, @i, @i)

set @i = @i + 1

end

select a from T where b = 1 or c < 3

|--Sort(DISTINCT ORDER BY:([T].[a] ASC))

|--Concatenation

|--Index Seek(OBJECT:([T].[Tb]), SEEK:([T].[b]=(1)) ORDERED FORWARD)

|--Index Seek(OBJECT:([T].[Tc]), SEEK:([T].[c] < (3)) ORDERED FORWARD)

This plan is very similar to the union all plan that we saw above. The optimizer rewrote the query as:

select a from T where b = 1

union

select a from T where c < 3

Note, however, that since the two queries that make up the union could return duplicate rows, we must use a union (which eliminates duplicates) rather than a union all (which does not). The concatenation operator implements union all while the sort distinct eliminates duplicates and turns the union all into a union. We refer to this type of plan as an “index union.”

Merge union

Now let’s change the query slightly:

select a from T where b = 1 or c = 3

|--Stream Aggregate(GROUP BY:([T].[a]))

|--Merge Join(Concatenation)

|--Index Seek(OBJECT:([T].[Tb]), SEEK:([T].[b]=(1)) ORDERED FORWARD)

|--Index Seek(OBJECT:([T].[Tc]), SEEK:([T].[c]=(3)) ORDERED FORWARD)

Instead of the concatenation and sort distinct operators, we now have a merge join (concatenation) and a stream aggregate. What happened? The merge join (concatenation) or “merge union” is not really a join at all. It is implemented by the same iterator as the merge join, but it really performs a union all while preserving the order of the input rows. Finally, we use the stream aggregate to eliminate duplicates. (See this post for more about using stream aggregate to eliminate duplicates.) This plan is generally a better choice since the sort distinct uses memory and could spill data to disk if it runs out of memory while the stream aggregate does not use memory.

So, why didn’t we use this plan before? Just like a merge join, the merge union requires that input data be sorted on the merge key (in this case column a). The non-clustered index Tb covers the explicit index key b and the clustering key a. Thus, this index returns rows in the order (b, a). However, with an equality predicate such as “b = 1”, column b is a constant so we actually get rows ordered by column a. The same thing happens with the index Tc and the predicate “c = 3”. So, we have two inputs that are both ordered by column a and we can use the merge union.

In the prior example, one of the predicates was “c < 3”. Because this predicate is an inequality, the index seek returns rows in the order (c, a). Since the rows are not strictly sorted by a, we cannot use the merge union.

Union of three indexes

The concatenation operator directly supports more than two inputs:

select a from T where a = 1 or b = 2 or c < 3

|--Sort(DISTINCT ORDER BY:([T].[a] ASC))

|--Concatenation

|--Clustered Index Seek(OBJECT:([T].[Ta]), SEEK:([T].[a]=(1)) ORDERED FORWARD)

|--Index Seek(OBJECT:([T].[Tb]), SEEK:([T].[b]=(2)) ORDERED FORWARD)

|--Index Seek(OBJECT:([T].[Tc]), SEEK:([T].[c] < (3)) ORDERED FORWARD)

Merge union only supports two inputs, but it can be cascaded to handle more than two inputs:

select a from T where a = 1 or b = 2 or c = 3

|--Stream Aggregate(GROUP BY:([T].[a]))

|--Merge Join(Concatenation)

| |--Clustered Index Seek(OBJECT:([T].[Ta]), SEEK:([T].[a]=(1)) ORDERED FORWARD)

| |--Index Seek(OBJECT:([T].[Tb]), SEEK:([T].[b]=(2)) ORDERED FORWARD)

|--Index Seek(OBJECT:([T].[Tc]), SEEK:([T].[c]=(3)) ORDERED FORWARD)

What columns does the union return?

A union only returns the columns that are common to all of its inputs. In all of the above index union examples, the only column that the indexes have in common is the clustering key a. (Recall that index Tb covers (b, a) while index Tc covers (c, a).) Thus, the union can only return column a. If we ask for other columns, we must perform a bookmark lookup. This is true even if one of the indexes in the union covers the extra columns. For example, if we ask for all three columns a, b, and c, we get a bookmark lookup even though column b is covered by Tb and column c is covered by Tc:

select a, b, c from T where b = 1 or c = 3

|--Nested Loops(Inner Join, OUTER REFERENCES:([T].[a]))

|--Stream Aggregate(GROUP BY:([T].[a]))

| |--Merge Join(Concatenation)

| |--Index Seek(OBJECT:([T].[Tb]), SEEK:([T].[b]=(1)) ORDERED FORWARD)

| |--Index Seek(OBJECT:([T].[Tc]), SEEK:([T].[c]=(3)) ORDERED FORWARD)

|--Clustered Index Seek(OBJECT:([T].[Ta]), SEEK:([T].[a]=[T].[a]) LOOKUP ORDERED FORWARD)

Index Examples and Tradeoffs

craigfr — Thu, 13 Jul 2006 23:12:00 GMT

The optimizer must choose an appropriate “access path” to read data from each table referenced in a query. The optimizer considers many factors when deciding which index to use, whether to do a scan or a seek, and whether to do a bookmark lookup. These factors include:

How many I/Os will a seek or scan of the index perform?
Are the keys of the index suitable for evaluating a predicate in the query?
How selective is the predicate? (That is, what percentage of the total rows in the table qualifies for this predicate? The lower this number the better.)
Does the index cover all of the necessary columns?

In this post, I’m going to give some examples of how these factors interact.

Schema

I’ll use this schema for all of the following examples:

create table T (a int, b int, c int, d int, x char(200))

create unique clustered index Ta on T(a)

create index Tb on T(b)

create index Tcd on T(c, d)

create index Tdc on T(d, c)

If you want to try the examples, I populated the table using the following script:

set nocount on

declare @i int

set @i = 0

while @i < 100000

begin

insert T values (@i, @i, @i, @i, @i)

set @i = @i + 1

end

I/O example

Consider this query:

select a, b from T

This query has no WHERE clause so we must use a scan. However, there are two indexes we can scan. There is the clustered index Ta and there is the non-clustered index Tb. Both of these indexes cover columns a and b. However, the clustered index also covers columns c and x. Because column x is a char(200), the total width of each row in the clustered index is over 200 bytes, fewer than 40 rows fit on each 8K page, and the index requires more than 2,500 pages to store all 100,000 rows. In contrast, the total width of each row in the non-clustered index, is only 8 bytes plus some overhead, hundreds of rows fit on each page, and the index requires fewer than 250 pages to store all 100,000 rows. By scanning the non-clustered index, we can execute the query while performing many fewer I/Os.

Thus, the better plan is:

|--Index Scan(OBJECT:([T].[Tb]))

Note that we can use sys.dm_db_index_physical_stats to compare the indexes:

select index_id, page_count

from sys.dm_db_index_physical_stats

(DB_ID('tempdb'), OBJECT_ID('T'), NULL, NULL, NULL)

index_id    page_count
----------- --------------------
1           2858
2           174
3           223
4           223

We can also use stats I/O and index hints to compare the number of I/Os for the two possible plans:

set statistics io on

select a, b from T with (index(Ta))

Table 'T'. Scan count 1, logical reads 2872, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

select a, b from T with (index(Tb))

Table 'T'. Scan count 1, logical reads 176, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Selectivity example

Consider this query:

select a from T

where c > 150 and c < 160 and d > 100 and d < 200

This query has two different predicates that we might use for an index seek. We can use the predicate on column c with the non-clustered index Tcd or we can use the predicate on column d with the non-clustered index Tdc. (Refer to my post on seek predicates for an explanation of why we cannot use a single index to satisfy both inequality predicates.)

The optimizer looks at the selectivity of the two predicates to determine which index to use. The predicate on column c selects only 9 rows while the predicate on column d selects 99 rows. Thus, it is cheaper to seek using the index Tcd and evaluate a residual predicate on column d for 9 rows than it is to seek using the index Tdc and evaluate a residual predicate on column c for 99 rows.

Here is the plan:

|--Index Seek(OBJECT:([T].[Tcd]), SEEK:([T].[c] > (150) AND [T].[c] < (160)), WHERE:([T].[d]>(100) AND [T].[d]<(200)) ORDERED FORWARD)

Seek vs. scan example

Consider these two queries:

select a from T where a between 1001 and 9000

select a from T where a between 101 and 90000

As you might expect, for the first query, the optimizer chooses a clustered index seek to satisfy the predicate on column a. Here is the plan:

|--Clustered Index Seek(OBJECT:([T].[Ta]), SEEK:([T].[a] >= CONVERT_IMPLICIT(int,[@1],0) AND [T].[a] <= CONVERT_IMPLICIT(int,[@2],0)) ORDERED FORWARD)

(Note that the parameters in this plan are due to auto-parameterization. When we execute this plan, @1 has the value 1001 and @2 has the value 9000.)

For the second query, instead of the clustered index seek, the optimizer chooses an index scan of the non-clustered index Tb and uses a residual predicate for the WHERE clause. Again, here is the plan:

|--Index Scan(OBJECT:([T].[Tb]), WHERE:([T].[a]>=(101) AND [T].[a]<=(90000)))

What happened? The predicate on the first query selects 8,000 out of 100,000 rows; this is about 8% of the table or about 230 pages of the clustered index. The predicate on the second query selects 89,000 rows; this is nearly 90% of the table and if we were to use the clustered index it would mean touching over 2,500 pages. By comparison, we can scan the entire non-clustered index Tb and touch only 174 pages. Thus, the optimizer chooses the plan that requires significantly fewer I/Os.

Seek with bookmark lookup vs. scan example

Consider these two queries:

select x from T where b between 101 and 200

select x from T where b between 1001 and 2000

We again have two plans from which to choose. We can scan the clustered index directly and apply the predicate on column b as a residual. Or, we can use the non-clustered index Tb and perform a seek using the predicate on column b then do a bookmark lookup on the clustered index to get the value of column x for each qualifying row. In my bookmark lookup post, I explained that bookmark lookups perform random I/Os which are very expensive. Thus, the plan with the bookmark lookup is only a good plan when the seek predicate is very selective.

The first query touches only 100 rows and the optimizer concludes that the bookmark lookup is worthwhile:

|--Nested Loops(Inner Join, OUTER REFERENCES:([T].[a], [Expr1005]) ...)
|--Index Seek(OBJECT:([T].[Tb]), SEEK:([T].[b] >= (101) AND [T].[b] <= (200)) ...)
|--Clustered Index Seek(OBJECT:([T].[Ta]), SEEK:([T].[a]=[T].[a]) LOOKUP ...)

The second query touches 1,000 rows. Although this is still only 1% of the table, the optimizer concludes that 1,000 random I/Os are more expensive than 2,800 sequential I/Os and opts for the clustered index scan:

|--Clustered Index Scan(OBJECT:([T].[Ta]), WHERE:([T].[b]>=(1001) AND [T].[b]<=(2000)))

Next up … Joins

There are still more topics and issues related to indexes, scans and seeks, and so forth, but I think it’s time to move on to something new so with my next post I’m going to start writing about joins. As always, I’m interested to hear what you have to say. If you have any comments or feedback, please let me know.

Seek Predicates

craigfr — Fri, 07 Jul 2006 23:36:00 GMT

Before SQL Server can perform an index seek, it must determine whether the keys of the index are suitable for evaluating a predicate in the query.

Single column indexes

Single column indexes are fairly straightforward. SQL Server can use single column indexes to answer most simple comparisons including equality and inequality (greater than, less than, etc.) comparisons. More complex expressions such as functions over a column and “like” predicates with a leading wildcard character will generally prevent SQL Server from using an index seek.

For example, suppose we have a single column index on a column “a.” We can use this index to seek on these predicates:

a = 3.14
a > 100
a between 0 and 99
a like ‘abc%’
a in (2, 3, 5, 7)

However, we cannot use it to seek on these predicates:

ABS(a) = 1
a + 1 = 9
a like ‘%abc’

Multi-column indexes

Multi-column indexes are slightly more complex. With a multi-column index, the order of the keys matters. It determines the sort order of the index and it affects the set of seek predicates that SQL Server can evaluate using the index.

For an easy way to visualize why order matters, think about the phone book. The phone book is like an index with the keys (last name, first name). The contents of the phone book are sorted by last name and it is easy to look someone up if we know their last name. However, if we have only a first name, it is very difficult to get a list of people with that name. We would need another phone book sorted on first name.

In the same way, if we have an index on two columns, we can only use the index to satisfy a predicate on the second column if we have an equality predicate on the first column. Even if we cannot use the index to satisfy the predicate on the second column, we may be able to use it on the first column. In this case, we introduce a residual predicate for the predicate on the second column. This is the same residual predicate that we use for scans.

For example, suppose we have a two column index on column “a” and “b.” We can use this index to seek on any of the predicates that worked on the single column index. We can also use it to seek on these additional predicates:

a = 3.14 and b = ‘pi’
a = ‘xyzzy’ and b <= 0

For the next set of examples, we can use the index to satisfy the predicate on column a, but not on column b. In these cases, we need a residual predicate.

a > 100 and b > 100
a like ‘abc%’ and b = 2

Finally, we cannot use the index to seek on the next set of predicates as we cannot seek even on column a. In these cases, we must use a different index (e.g., one where column b is the leading column) or we must use a scan with a residual predicate.

b = 0
a + 1 = 9 and b between 1 and 9
a like ‘%abc’ and b in (1, 3, 5)

A slightly more concrete example

Consider the following schema:

create table person (id int, last_name varchar(30), first_name varchar(30))
create unique clustered index person_id on person (id)
create index person_name on person (last_name, first_name)

Here are three queries and their corresponding text showplan. The first query seeks on both columns of the person_name index. The second query seeks on the first column only and uses a residual predicate to evaluate first_name. The third query cannot seek and uses a scan with a residual predicate.

select id from person where last_name = 'Doe' and first_name = 'John'
|--Index Seek(OBJECT:([person].[person_name]), SEEK:([person].[last_name]='Doe' AND [person].[first_name]='John'))

select id from person where last_name > 'Doe' and first_name = 'John'
|--Index Seek(OBJECT:([person].[person_name]), SEEK:([person].[last_name] > 'Doe'), WHERE:([person].[first_name]='John'))

select id from person where last_name like '%oe' and first_name = 'John'
|--Index Scan(OBJECT:([person].[person_name]), WHERE:([person].[first_name]='John' AND [person].[last_name] like '%oe'))

Note: In case you are trying to reproduce these plans, in this and some of my prior examples, I’ve used index hints (which I haven’t shown) to ensure that I get the plan I want to illustrate without having to insert data into the table.

A bit more about index keys

In most cases, the index keys are the set of columns that you specify in the create index statement. However, when you create a non-unique non-clustered index on a table with a clustered index, we append the clustered index keys to the non-clustered index keys if they are not explicitly part of the non-clustered index keys. You can seek on these implicit keys just as if you specified them explicitly.

For example, given this schema:

create table T_heap (a int, b int, c int, d int, e int, f int)
create index T_heap_a on T_heap (a)
create index T_heap_bc on T_heap (b, c)
create index T_heap_d on T_heap (d) include (e)
create unique index T_heap_f on T_heap (f)

create table T_clu (a int, b int, c int, d int, e int, f int)
create unique clustered index T_clu_a on T_clu (a)
create index T_clu_b on T_clu (b)
create index T_clu_ac on T_clu (a, c)
create index T_clu_d on T_clu (d) include (e)
create unique index T_clu_f on T_clu (f)

The key columns and covered columns for each index are:

Index	Key Columns	Covered Columns
T_heap_a	a	a
T_heap_bc	b, c	b, c
T_heap_d	d	d, e
T_heap_f	f	f
T_clu_a	a	a, b, c, d, e
T_clu_b	b, a	a, b
T_clu_ac	a, c	a, c
T_clu_d	d, a	a, d, e
T_clu_f	f	a, f

Note that each of the non-clustered indexes on T_clu include the clustered index key column a with the exception of T_clu_f which is a unique index.

To be continued one last time …

I’m planning one more post about scans and seeks. I’ll write a bit more about some of the tradeoffs that SQL Server considers when deciding which index to use and whether to perform a scan, a seek, or a seek with a bookmark lookup.

Bookmark Lookup

craigfr — Fri, 30 Jun 2006 23:05:00 GMT

In my last post, I explained how SQL Server can use an index to efficiently locate rows that qualify for a predicate. When deciding whether to use an index, SQL Server considers several factors. These factors include checking whether the index covers all of the columns that the query references (for the table in question).

What does it mean for an index to cover a column?

The heap or clustered index for a table (often called the “base table”) contains (or covers) all columns in the table. Non-clustered indexes, on the other hand, contain (or cover) only a subset of the columns in the table. By limiting the set of columns stored in a non-clustered index, we can store more rows on each page. Thus, we save disk space and improve the efficiency of seeks and scans by reducing the number of I/Os and the number of pages that we touch.

Each non-clustered index covers the key columns that were specified when it was created. Also, if the base table is a clustered index, each non-clustered index on this table covers the clustered index keys (often called the “clustering keys”) regardless of whether they are part of the non-clustered index’s key columns. In SQL Server 2005, we can also add additional non-key columns to a non-clustered index using the “include” clause of the create index statement.

For example, given this schema:

create table T_heap (a int, b int, c int, d int, e int)

create index T_heap_a on T_heap (a)

create index T_heap_bc on T_heap (b, c)

create index T_heap_d on T_heap (d) include (e)

create table T_clu (a int, b int, c int, d int, e int)

create unique clustered index T_clu_a on T_clu (a)

create index T_clu_b on T_clu (b)

create index T_clu_ac on T_clu (a, c)

create index T_clu_d on T_clu (d) include (e)

The covered columns for each index are:

Index	Covered Columns
T_heap_a	a
T_heap_bc	b, c
T_heap_d	d, e
T_clu_a	a, b, c, d, e
T_clu_b	a, b
T_clu_ac	a, c
T_clu_d	a, d, e

Note that order is not relevant for covered columns.

How does this relate to index seeks and bookmark lookups?

Consider this query (using the above schema):

select e from T_clu where b = 2

At first glance, this query looks like a perfect candidate for an index seek using the non-clustered index on column b (T_clu_b) with the seek predicate “b = 2”. However, this index does not cover column e so a seek or scan of this index cannot return the value of column e. The solution is simple. For each row that we fetch from the non-clustered index, we can lookup the value of column e in the clustered index. We call this operation a “bookmark lookup.” A “bookmark” is a pointer to the row in the heap or clustered index. We store the bookmark for each row in the non-clustered index precisely so that we can always navigate from the non-clustered index to the corresponding row in the base table.

The following figure illustrates a bookmark lookup:

Showplan Samples

In SQL Server 2000, we implement bookmark lookup using a dedicated iterator whether the base table is a clustered index or heap:

|--Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([T_clu]))
|--Index Seek(OBJECT:([T_clu].[T_clu_b]), SEEK:([T_clu].[b]=2) ORDERED FORWARD)

In SQL Server 2005, we use a regular clustered index seek if the base table is a clustered index or a RID (record id) lookup if the base table is a heap:

|--Nested Loops(Inner Join, OUTER REFERENCES:([T_clu].[a]))
|--Index Seek(OBJECT:([T_clu].[T_clu_b]), SEEK:([tempdb].[dbo].[T_clu].[b]=(2)) ORDERED FORWARD)
|--Clustered Index Seek(OBJECT:([T_clu].[T_clu_a]), SEEK:([T_clu].[a]= [T_clu].[a]) LOOKUP ORDERED FORWARD)

|--Nested Loops(Inner Join, OUTER REFERENCES:([Bmk1000]))
|--Index Seek(OBJECT:([T_heap].[T_heap_a]), SEEK:([T_heap].[a]=(2)) ORDERED FORWARD)
|--RID Lookup(OBJECT:([T_heap]), SEEK:([Bmk1000]=[Bmk1000]) LOOKUP ORDERED FORWARD)

You can tell that the clustered index seek is a bookmark lookup by the LOOKUP keyword in text showplan or by the attribute Lookup=“1” in XML showplan. I will explain the behavior of the nested loops join in a future post. The loop join and clustered index seek (or RID lookup) perform the same operation as the bookmark lookup in SQL Server 2000.

Tradeoffs

Bookmark lookup is not a cheap operation. Assuming (as is commonly the case) that there is no correlation between the non-clustered and clustered index keys, each bookmark lookup performs a random I/O into the clustered index. Random I/Os are very expensive. When comparing various plan alternatives including scans, seeks, and seeks with bookmark lookups, the optimizer must decide whether it is cheaper to perform more sequential I/Os and touch more rows using an index scan or a seek with a less selective predicate that covers all required columns or to perform fewer random I/Os and touch fewer rows using a seek with a more selective predicate and a bookmark lookup.

In some cases, you can introduce a better plan option by creating a new index or by adding one or more columns to an existing index so as to eliminate a bookmark lookup or change a scan into a seek. In SQL Server 2000, the only way to add columns to an index is to add additional key columns. As I mentioned above, in SQL Server 2005, you can add also columns using the include clause of the create index statement. Included columns are more efficient than key columns; they save disk space and make searching and updating the index more efficient.

Of course, whenever you create new indexes or add new key or included columns to an existing index, you do consume additional disk space and you make it more expensive to search and update the index. Thus, you must balance the frequency and importance of the queries that benefit from the new index against the queries or updates that are slower.

To be continued again …

In my next post, I’ll go into a bit more detail about when we can perform index seeks and take a look at single vs. multi-column indexes.

Scans vs. Seeks

craigfr — Tue, 27 Jun 2006 00:40:00 GMT

Scans and seeks are the iterators that SQL Server uses to read data from tables and indexes. These iterators are among the most fundamental ones that we support. They appear in nearly every query plan.

What is the difference between a scan and a seek?

A scan returns the entire table or index. A seek efficiently returns rows from one or more ranges of an index based on a predicate. For example, consider the following query:

select OrderDate from Orders where OrderKey = 2

Scan

With a scan, we read each row in the orders table, evaluate the predicate “where OrderKey = 2” and, if the predicate is true (i.e., if the row qualifies), return the row. In this case, we refer to the predicate as a “residual” predicate. To maximize performance, whenever possible we evaluate the residual predicate in the scan. However, if the predicate is too expensive, we may evaluate it in a separate filter iterator. The residual predicate appears in text showplan with the WHERE keyword or in XML showplan with the <Predicate> tag.

Here is the text showplan (slightly edited for brevity) for this query using a scan:

|--Table Scan(OBJECT:([ORDERS]), WHERE:([ORDERKEY]=(2)))

The following figure illustrates the scan:

Since a scan touches every row in the table whether or not it qualifies, the cost is proportional to the total number of rows in the table. Thus, a scan is an efficient strategy if the table is small or if most of the rows qualify for the predicate. However, if the table is large and if most of the rows do not qualify, we touch many more pages and rows and perform many more I/Os than is necessary.

Seek

Going back to the example, if we have an index on OrderKey, a seek may be a better plan. With a seek, we use the index to navigate directly to those rows that satisfy the predicate. In this case, we refer to the predicate as a “seek” predicate. In most cases, we do not need to re-evaluate the seek predicate as a residual predicate; the index ensures that the seek only returns rows that qualify. The seek predicate appears in the text showplan with the SEEK keyword or in XML showplan with the <SeekPredicates> tag.

Here is the text showplan for the same query using a seek:

|--Index Seek(OBJECT:([ORDERS].[OKEY_IDX]), SEEK:([ORDERKEY]=(2)) ORDERED FORWARD)

The following figure illustrates the seek:

Since a seek only touches rows that qualify and pages that contain these qualifying rows, the cost is proportional to the number of qualifying rows and pages rather than to the total number of rows in the table. Thus, a seek is generally a more efficient strategy if we have a highly selective seek predicate; that is, if we have a seek predicate that eliminates a large fraction of the table.

A note about showplan

In showplan, we distinguish between scans and seeks as well as between scans on heaps (an object with no index), clustered indexes, and non-clustered indexes. The following table shows all of the valid combinations:

	Scan	Seek
Heap	Table Scan
Clustered Index	Clustered Index Scan	Clustered Index Seek
Non-clustered Index	Index Scan	Index Seek

To be continued …

There is much more to write about scans and seeks. In my next post, I will continue by discussing bookmark lookup and how bookmark lookup relates to scans and seeks.