Brad McGehee on "How to Interpret Query Execution Plans in SQL Server 2005/2008". Presented to the San Francisco SQL Server User Group in March 2009.

1. Presented to the
San Francisco SQL Server User Group
www.bayareasql.org
March 11, 2009
Brad M McGehee
Microsoft SQL Server MVP
Director of DBA Education
Red Gate Software
bradmcgehee@hotmail.com

2. You are a SQL Server DBA or developer with
novice to intermediate knowledge of SQL Server.
You have a basic understanding of indexing and
Transact-SQL.
You want to learn the basics of how to read and
interpret Execution Plans so that you can better
understand how your queries are executing, and
so that you can better figure out ways to
optimize them.
The difference between a run-of-the-mill DBA/Developer from an exceptional DBA/Developer is that the
exceptional DBA/Developer thoroughly understands how to use their available tools to their full potential.

3. A execution plan, simply put, describes the data
retrieval/storage methods chosen by the Query
Optimizer to execute a specific query.
So why is this important to know?
If you understand how a query was executed by
SQL Server, you have the information you need to
help you to figure out ways to potentially
optimize it.

4. T-SQL is sent to the relational engine.
T-SQL is parsed to check to see if it is written correctly.
T-SQL is next run through the algebrizer, which resolves all the names
of the various objects, tables and columns.
Algebrizer output is sent to Query Optimizer.
Then:
Trivial plan may be generated.
Otherwise, cost-based calculations are performed to identify the best way to execute the
query. In other words, an execution plan is created.
Index and column statistics are used during above cost-based
calculations to help the query optimizer determine the best execution
plan. The better the statistics, the better the execution plan.
Note: DDL T-SQL is not optimized, only DML T-SQL

5. The creation of an execution plan takes time.
Not every execution option is always explored, a “good
enough” execution plan is often generated, then sent to the
database engine for execution.
The execution plan is estimated, and may change when the
T-SQL is actually executed by the database engine.
Execution plans are usually cached (in the plan cache) for
later use so that it can be reused if an identical (or
paramerized) query is submitted for execution again.
Reusing a cached execution plan can save time because a
new execution plan does not have to be recreated each
time the same query is re-executed.

6. Text (Deprecated)
Harder for many people to read
XML (Storage Format)
XML code is not really designed to be read directly by
DBAs
Can be saved and shared with others (portable)
Can be displayed in graphical format (main use)
Graphical (Display Format)
Generally easier to read and understand by beginners
Is produced from XML execution plan
Our focus today
Demo

8. Estimated
Produced without running the query.
Displays estimated data only.
Can save time and resources.
Can’t be used if the query creates object it needs to use: i.e.
temp table.
Not aways accurate, can be misleading, especially if data is
skewed, or the statistics are outdated, or if parallelism is
involved.
Actual
Produced after a query actually runs, may or may not be same as
estimated execution plan.
Displays estimated and actual results.
Demo

9. SSMS (our choice for today)
SET commands (some shown in previous demo)
Profiler (Showplan XML Event, shows estimated
plan)
SQL Server 2005 Performance Dashboard
SQL Server 2008 Data Collector

10. Demo
Overview of Graphical Execution Plan Screen
Using the Zoom Button (Around, In, Out, Fit)
Learning to Read from Right to Left and Top to Bottom
Learning about Icons (operators)
Learning about costs (per operator)
Learning about Tool Tips (and Properties)
Learning about Arrows
Executing Multiple Queries

11. Each operator implements a single basic
operation, such as:
Scanning data from a table
Seeking data in a table
Aggregating data
Sorting
Joining two data sets
Etc.
In total, there are 79 different operator that can
be included in an execution plan.

12. Logical and physical operators

13. Logical and physical operators

14. There are 79 Graphical Execution Plan icons.

15. SELECT
Table Scan
Clustered Index Scan
Clustered Index Seek
Non-Clustered Scan
Non-Clustered Index Seek
RID Lookup
Key Lookup
Sort
Joins (loop, merge, hash)
Parallelism (special case)

16. Represents the end results of a SELECT query.
Good place to start when evaluating any
execution plan.
To optimize performance, the number of rows
that are returned should be the minimum
number of rows necessary to meet the needs of
the query.
Similar icons are available for INSERT, UPDATE,
and DELETE.

17. Seeing a table scan often indicates a problem that needs to be
addressed.
A table scan indicates that every row in the table had to be examined
to see if it met the query criteria, which can mean slow performance if
there are a large numbers of rows.
A table scan indicates there is no clustered index on the table, and the
table is a heap.
In most cases, you will want to add a clustered index to every table, as
it has the potential of boosting the performance of the query, even if a
clustered index scan is conducted.
This is because leaf nodes of the clustered index are stored together
(logically, and hopefully physically). In a heap, they are not, which can
hurt performance.

18. A clustered index scan is a scan of all the rows of
a table that has a clustered index.
Like a table scan, clustered index scans can be
slow and use up lots of server resources.
Generally, clustered index scans should generally
be avoided (but better than table scans).
On the other hand, when tables are small or
many rows are returned, then a clustered index
scan might be the fastest way to return data.

19. If there is an available and useful index, and there
is a sargeable WHERE clause, the query optimizer
can usually, very quickly, identify the rows to be
returned and return them without having to scan
each row of the table.
Ideally, for best query performance, clustered
index seeks should be as used often as feasible.
Consider them the “golden standard” for
returning data.
Of course, there are exceptions, as we will see in
the demo.

20. All records in the table are scanned, and all rows
that match the WHERE clause are returned.
As with all scans, it can be slow and require extra
I/O resources.
Generally, non-clustered index scans should be
avoided.

21. A non-clustered index is used to identify the row(s)
to be returned, so every row does not need to be
scanned (assumes sargeable WHERE clause).
This is generally much faster than a non-clustered
index scan.
Like clustered index seeks, non-clustered index
seeks are generally a good thing.
One exception is if bookmark (RID or Key) lookups
occur as part of the non-clustered index seek, then
performance may lag if many rows are returned.

22. A RID Lookup is generally an indicator of a
performance issue.
A RID Lookup is a form of a bookmark index lookup
on a table without a clustered index (a heap).
While RID Lookups are often faster than most
“scans,” this is often not the case if many rows have
to be returned.
Generally, RID Lookups should be eliminated with
the addition of an appropriate clustered index, and if
necessary, a covering or included index.

23. A key lookup is often an indicator of potentially less
than optimal performance.
A key lookup is a bookmark lookup on a table with a
clustered index.
A key lookup is generally faster than a RID lookup.
While key lookups are often faster than most
“scans,” this is not always the case, especially if a lot
of data needs to be returned.
Often, key lookups should be eliminated with the
addition of a covering or included index.

24. Sorts occur when you specify that returned data
be ordered.
Sorts may also occur even if you don’t use the
ORDER clause.
Sorts are normal and aren’t generally a problem.
But if you return too much data, then sorts may
take a lot of resources (including tempdb), and
you should identify ways of reducing the number
of rows returned.

25. Loop: For each row in the top (outer) input, scan the bottom
(inner) input, and output matching rows.
Merge: Match rows from two suitably sorted input tables
exploiting their sort order.
Hash: Use each row from the top input (table) to build a hash
table, and each row from the bottom input (table) to probe into
the hash table, outputting all matching rows.
More on next page

26. There is no “ideal join,” it all depends on the data being
joined.
A join can occur in an execution plan even if there is no JOIN
statement in a query.
From a resource perspective, a nested loop join uses fewer
resources, and seeing one generally is a good indicator of
good overall performance. Often best for smaller joins.
Merge and hash joints use more resources and may be an
indicator that too much data is being returned.
Demo

27. Parallelism is used to take a query, break it into two or more
parts, execute it in parallel, then recombine the parts.
Distribute Stream: Takes a single input stream and produces multiple output
streams.
Gather Stream: Consumes multiple input streams and produces a single
output stream by combining the input streams.
Repartition Stream: Consumes multiple streams and produces multiple
streams of records.
Bitmap Create: Bitmap filtering speeds up query execution by eliminating
rows with key values that cannot produce any join records before passing rows
through another operator.
Parallelism may or may not boost query performance.
Note: The two arrows in a regular icon indicate
parallelism was used for that operator

28. This is just a small sample of the things you can do with
Graphical Execution Plans.
The learning curve for learning about Graphical Execution
Plans is high, but worth the effort.
Graphical Execution Plans are a powerful tool to help DBAs
understand how a query executes.
Based on the information provided by an execution plan, and
the DBA’s knowledge of SQL Server, many queries (and
indexes) can often be optimized.

29. Please ask questions loud enough for everyone
to hear.

30. Free E-Books:
www.sqlservercentral.com/Books
Check these out:
SQL Server 2005/2008 Books Online (of course)
www.SQLServerCentral.com
www.Simple-Talk.com
www.SQL-Server-Performance.Com
Contact me at:
bradmcgehee@hotmail.com
Blogs:
www.simple-talk.com/community/blogs/brad_mcgehee/default.aspx
http://www.sqlservercentral.com/blogs/aloha_dba/default.aspx
http://twitter.com/bradmcgehee