SQL Server Query Execution

Plan Analysis
By : Brad McGehee
Apr 04, 2006

When it comes time to analyze the performance of a specific query, one of

the best methods is to view the query execution plan. A query execution plan
outlines how the SQL Server query optimizer actually ran (or will run) a specific
query. This information if very valuable when it comes time to find out why a specific
query is running slow.

There are several different ways to view a query's execution plan. They include:

• From within Query Analyzer is an option called "Show Execution Plan"

(located on the Query drop-down menu). If you turn this option on, then
whenever you run a query in Query Analyzer, you will get a query execution
plan (in graphical format) displayed in a separate window.

• If you want to see an execution plan, but you don't want to run the query,
you can choose the option "Display Estimated Execution Plan" (located on the
Query drop-down menu). When you select this option, immediately an
execution plan (in graphical format) will appear. The difference between these
two (if any) is accountable to the fact that when a query is really run (not
simulated, as in this option), current operations of the server are also
considered. In most cases, plans created by either method will produce
similar results.

• When you create a SQL Server Profiler trace, one of the events you can
collect is called: MISC: Execution Plan. This information (in text form) shows
the execution plan used by the query optimizer to execute the query.
 • From within Query Analyzer, you can run the command SET
SHOWPLAN_TEXT ON. Once you run this command, any query you execute in
this Query Analyzer sessions will not be run, but a text-based version of the
query plan will be displayed. If the query you are running uses temp tables,
then you will have to run the command, SET STATISTICS PROFILE ON before
running the query.

Of these options, I prefer using the "Show Execution Plan", which produces a
graphical output and considers current server operations. [7.0, 2000] Updated 8-5-
2005

*****

If you see any of the following in an execution plan, you should consider them
warning signs and investigate them for potential performance problems. Each of
them are less than ideal from a performance perspective.

• Index or table scans: May indicate a need for better or additional indexes.

• Bookmark Lookups: Consider changing the current clustered index, consider

using a covering index, limit the number of columns in the SELECT statement.

• Filter: Remove any functions in the WHERE clause, don't include wiews in
your Transact-SQL code, may need additional indexes.

• Sort: Does the data really need to be sorted? Can an index be used to avoid
sorting? Can sorting be done at the client more efficiently?

It is not always possible to avoid these, but the more you can avoid them, the faster
query performance will be. [7.0, 2000, 2005] Updated 8-5-2005

*****

If you have a stored procedure, or other batch Transact-SQL code that uses
temp tables, you cannot use the "Display Estimated Execution Plan" option
in the Query Analyzer or Management Studio to evaluate it. Instead, you must
actually run the stored procedure or batch code. This is because when a query is run
using the "Display Estimated Execution Plan" option, it is not really run, and temp
tables are not created. Since they are not created, any references to them in the
code will fail, which prevents an estimated execution plan from being created.

On the other hand, if you use a table variable instead of a temp table, you can use
the "Display Estimated Execution Plan" option [7.0, 2000, 2005] Updated 8-5-2005

*****

If you have a very complex query you are analyzing in Query Analyzer or
Management Studio as a graphical query execution plan, the resulting plan can be
very difficult to view and analyze. You may find it easier to break down the query
into its logical components, analyzing each component separately. [7.0, 2000, 2005]
Updated 8-5-2005

*****

The results of a graphical query execution plan are not always easy to read
and interpret. Keep the following in mind when viewing a graphical execution plan:

• In very complex query plans, the plan is divided into many parts, with each
part listed one on top of the other on the screen. Each part represents a
separate process or step that the query optimizer has to perform in order to
get to the final results.

• Each of the execution plan steps is often broken down into smaller sub-steps.
Unfortunately, they are displayed on the screen from right to left. This means
you must scroll to the far right of the graphical query plan to see where each
step starts.

• Each of the sub-steps and steps is connected by an arrow, showing the path
(order) taken of the query when it was executed.

• Eventually, all of the parts come together at the top left side of the screen.
 • If you move your cursor above any of the steps or sub-steps, a pop-up
windows is displayed, providing more detailed information about this
particular step or sub-step.

• If you move your cursor over any of the arrows connecting the steps and sub-
steps, you see a pop-up window showing how many records are being moved
from one step or sub-step to another step or sub-step.

[7.0, 2000, 2005] Updated 8-5-2005

Reference:
http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx