Hướng dẫn học Microsoft SQL Server 2008 part 136 pptx

Nielsen p09.tex V4 - 07/21/2009 4:06pm Page 1312
www.getcoolebook.com
Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1313
Interpreting Query
Execution Plans
IN THIS CHAPTER
The language of performance
tuning and optimization
Viewing, saving, and working
with query execution plans
Reading query execution
operators
I
believe that intelligence is the ability to abstract — to create something new
at a higher lever based on more primitive constructs. The ability to express
thoughts using words composed of letters and simple sounds is abstraction;
to turn beats and notes into a melody is abstraction; and to turn 1s a 0s in CPU
registers into a programming language and then use that language to develop an
application represents multiple layers of abstraction.
Interpreting SQL Server query execution plans is abstraction inside-out.
SQL, as a declarative language, is an interesting study of abstraction because
the underlying primitive operations that execute the query are dynamically
determined based on more than just the SQL query.
The art of SQL Server performance tuning and optimization (PTO) is essentially
the skill of reading the query execution plans and understanding how to
manipulate the factors that determine the physical operations in an effort to
improve performance. The operations inside a query execution plan are the
language of SQL Server PTO, which is why this part of the book begins with
reading and interpreting the query execution plan.
Viewing Query Execution Plans
The SQL Server development team has exposed the query execution plan in sev-

eral places and in several formats, making it easy to find, view, and work with
query execution plans:
■ Management Studio’s Query Editor can display the estimated or actual
query execution plan as a graphic or as XML.
■ Showplans return the query plan as a message or a result set.
1313
www.getcoolebook.com
Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1314
Part IX Performance Tuning and Optimization
■ SQL Profiler can capture the query execution plan as plain text or as XML that can be viewed
in graphic form.
■ Query plans in cache may be viewed using dynamic management views.
Additionally, the query execution plan can be saved as an XML file and opened later using Management
Studio’s Query Editor.
What’s New with Query Execution Plans?
T
here’s very little that’s new regarding viewing query execution plans, but there are a few new tricks to
working with query execution plans in SQL Server 2008:
■ Management Studio’s Query Editor can switch the graphical query execution plan into
XML from the context menu.
■ A saved query execution plan now includes the full query, so when it’s re-opened, the
original source query can be viewed in the Query Editor.
■ The XML query execution plan is formatted better.
■ The Query Editor can now open the XML query execution plan that’s returned from
the sys.dm_exec_query_plan()dynamic management function as a graphical
plan with a single click.
Estimated query execution plans
SQL Server can return just the estimated query execution plan before the query is executed, or it can
return the actual query execution plan with the results of the query.
The difference between the estimated and the actual isn’t the plan — the sequence of logical and

physical operations is identical; the only difference is the estimated vs. actual number of rows returned
by each operation. Before the query is executed, the Query Optimizer will estimate the number of rows
based on statistics and use that estimate in determining the plan. After the query is executed, the query
processor can add to the plan the actual number of rows processed by each operation.
The estimated query execution plan may be viewed by selecting the query in the Query Editor and
either clicking the Display Estimated Execution Plan button in the toolbar, selecting Query ➪ Display
Estimated Execution Plan, or by pressing Ctrl+L.
Because the query isn’t actually executed, the estimated query execution plan should display in the
Execution Plan tab rather quickly.
The Query Editor’s execution plan
The data flow in a query plan is from right to left, bottom to top, as shown in Figure 63-1. Each
operation is presented as an icon. The Query Editor isn’t just a static display:
1314
www.getcoolebook.com
Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1315
Interpreting Query Execution Plans 63
■ Mousing over the logical operation causes a dialog to appear containing detailed information
about the logical operation, including the logical cost and the portion of the query handled by
the operation.
■ Mousing over a connector line presents detailed information about how much data is being
moved by that connector.
■ The Property window also presents detailed information about any operation or connector.
The display may be zoomed or sized to fit using the right-click context menu.
FIGURE 63-1
Query execution plans show the operations SQL Server uses to solve the query.
To walk through the query execution plan shown in Figure 63-1:
1. In the upper-right corner of the plan, the index seek operation is finding every row with
ProductID = 757 using an index seek operation against the [WorkOrder.IX_WorkOrder_
ProductID]
non-clustered index.

1315
www.getcoolebook.com
Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1316
Part IX Performance Tuning and Optimization
2. The nested loop operation receives every row from the index seek, and asks for those same
rows from the clustered index, calling the key lookup operation. Just ignore the compute
scalar operation, as it’s only handling a type conversion.
3. The nested loop assembles, or joins, the data from the index seek and key lookup and passes
the data to the select operation, which returns the correct columns to the client.
Note the following key pieces of information on the query plan:
■ The type of operation. Key operations are listed later in Table 63-1.
■ The object, listed below the operator and in the pop-up info box, is the actual index hit by the
operation.
■ The estimated number of rows, as the Query Optimizer uses the estimated number of rows to
choose the best query execution plan.
■ The estimated operator cost and the estimated subtree cost are relative values used by the
Query Optimizer. When tuning a query, these are critical values to watch. I typically read the
cost as cost times 1,000. For example, I’ll read .0051234 as 5, or .3255786 as 325, to make it
easier to think through the plans.
Plans can also be saved to a plan file (
.sqlplan) to be reexamined later. Re-opening a plan opens the
graphical execution plan. The context menu has a new option to edit the SQL query, which opens the
original SQL statement in a new Query Editor tab.
Returning the plan with showplans
In addition to the graphical execution plan, the Showplan options reveal the execution plan with some
additional detail.
Just as the display-estimated-execution-plan Query Editor option, when showplan is on, SQL Server
will return the query execution plan but won’t execute the statement.
SET SHOWPLAN must be the only
statement in the batch.

SET SHOWPLAN comesisthreeflavors:ALL, TEXT,andXML:
■
SHOWPLAN_ALL displays the operators as a result set. It exposes the same information as
the graphical execution plan. The executing statement is returned in the first row and every
operator is returned as subsequent rows. (This is a deprecated feature and will be eliminated
in a future version.)
■
SHOWPLAN_TEXT is very similar to SHOWPLAN_ALL except that the executing statement and
the operations are in separate result sets and only the
stmt text (first column) is displayed.
The
SHOWPLAN_TEXT option, along with the SET STATISTICS options, may also be toggled
graphically within Query Editor. Use the context menu’s Query Options command to open the
Query Properties and you can find the showplan options by selecting Execution ➪ Advanced.
(This is also a deprecated feature that will be eliminated in a future version.)
■
SHOWPLAN_XML displays more detail than any other method of viewing the execution
plan, and it offers the benefit of storing and displaying unstructured data, so it can dis-
play additional information that may not pertain to all execution plans. For example, in the
<Statement> element, SHOWPLAN_XML displays the Query Optimizer optimization level,
or the reason why the Query Optimizer returned this execution plan. For the XML version of
1316
www.getcoolebook.com
Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1317
Interpreting Query Execution Plans 63
SHOWPLAN, the ‘‘Include actual execution’’ Query Editor option must be off. In addition, if the
query results are set to grid, then the grid will offer a link to open the XML using the browser.
Another way to gather the execution plan is the
SET STATISTICS PROFILE ON command, which exe-
cutes the query and then supplies the same detail as

SHOWPLAN_ALL with the addition of actual row
counts and execution counts. This is the result set equivalent of the
SHOW ACTUAL execution plan. This
is a deprecated feature, to be eliminated in a future version.
SQL Profiler’s execution plans
Within the Performance event category, SQL Server Profiler includes several showplan events. The
Showplan XML event includes the XML for the query execution plan, which SQL Profiler displays in
a graphical form. It includes the same features as the Query Editor to mouse over the operation to see
more properties and zoom the display.
Saving the plan is possible with SQL Profiler, but it’s well hidden: If you right-click anywhere in the
upper pane on the line of a Showplan XML or Showplan XML Statistics Profile event, you can choose
to ‘‘Extract Event Data.’’ This enables you to save the plan as a
.sqlplan file. Cool add!
Examining plans using dynamic management views
Dynamic management views, or DMVs, previously introduced with SQL Server 2005, provide an excel-
lent window into SQL Server’s internals. Three of the DMVs expose the query execution plans currently
in the cache:
■
sys.dm_exec_cached_plans: Returns the plan type, memory size, and usecounts
■
sys.dm_exec_query_stats: Returns several aggregate execution statistics (e.g.,
last_execution_time, max_elapsed_time)
■
sys.dm_exec_requests: Returns plans that are currently executing
Each of these DMVs returns a plan handle (a binary identifier of the query execution plan in memory)
that can be passed to one of the following dynamic management functions with a
CROSS APPLY to
extract the query text or the query execution plan:
■
sys.dm_exec_query_plan(plan_handle): Returns the query execution plan in XML.

Note that for some very complex queries, if the XML nesting level is greater than 128, this
method of extracting the query plan will fail. Use the next method instead.
■
sys.dm_exec_text_query_plan(plan_handle): Returns the query execution plan as a
text showplan
■
sys.dm_exec_sql_text(plan_handle): Returns the query SQL statement
The code example in Figure 63-2 pulls together data from the DMVs to view the original SQL
statements and query execution plans from the cache.
1317
www.getcoolebook.com
Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1318
Part IX Performance Tuning and Optimization
FIGURE 63-2
Using DMVs, it’s possible to view the SQL code and the query execution plan in the procedure cache.
Clicking the XML in the right-most column opens another tab with a graphical view of the selected
query execution plan.
Interpreting the Query Execution Plan
Reading query execution plans may seem difficult at first; there are several types of complex icons, a ton
of detail, and the sheer scope of some query plans can be overwhelming.
SQL server uses about 60 operators. Some represent specific physical tasks, while most logically
represent a collection of hidden tasks. Table 63-1 lists the key operators regarding select queries and
indexing.
1318
www.getcoolebook.com
Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1319
Interpreting Query Execution Plans 63
TABLE 63-1
Query Execution Plan Operators
Icon Definition Description

Clustered index
scan
In a clustered index scan, SQL Server reads the entire clustered index, typically
sequentially, but it can be otherwise depending on the isolation level and the
fragmentation. SQL Server chooses this operation when the set of rows requested
by the
WHERE clause or join condition is a large percentage of rows needed
from the table or no index is available to select the range.
Table scan A table scan is similar to a clustered index scan but it scans a heap.
Clustered index
seek
In a clustered index seek, SQL Server rapidly navigates the clustered index b-tree
to retrieve specific rows. The benefit of the clustered index seek is that when the
row(s) are determined, all the columns are immediately available.
Hash match A hash match is an unordered join method that builds a temp table and
iteratively matches with data from another table. A hash match is more efficient if
one table is significantly larger than the other table. This is the worst-case join
method and is used when no suitable index is available.
Merge join The merge join is the fastest method of joining two tables if both tables are
pre-sorted.
Nested loop A nested loop iterates through the first table (or intermediate result set if in the
middle of the query plan), finding matching row(s) in the second table for each
row from the first. Typically, nested-loop joins are best when a large index is
joined with a small table.
Index scan
(non-clustered )
In a non-clustered index scan, SQL Server reads through the entire index
sequentially looking for the data.
Index seek
(non-clustered )

A non-clustered index seek navigates the b-tree index from the root node,
through the intermediate node(s), to the leaf node, and finally to the row. The
benefit of a nonclustered index seek is that it tends to be narrow (have few
columns), so more rows can fit on a page. Once the correct row is identified, if
all the required columns are found in the index, then the seek is complete
because the index covers the needs of the query. If a range is required, an index
seek operation can seek to the start of the range and then sequentially read to
the end of the range.
RID lookup The RID lookup locates rows in the data pages of a heap (a table without a
clustered index). Typically, a RID lookup works with a nested loop to locate the
data pages following a non-clustered index seek or scan.
Filter In some situations, SQL Server retrieves all the data from a table and then uses
filter operations to select the correct rows. Sometimes the Query Optimizer uses a
Filter for performance reasons, but it’s more often due to the lack of a useful
index.
Sort In some situations SQL Server retrieves all the data from a table and then sorts
the data to prepare it for operations to perform the
ORDER BY. While the filters
and sorts are themselves fast operations, they need to examine all the data, which
means a slower scan is required. These typically indicate a lack of useful indexes.
Spool In a spool operation, SQL Server has to save a temporary set of data.
1319
www.getcoolebook.com
Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1320
Part IX Performance Tuning and Optimization
Summary
If you’re new to SQL Server performance tuning and optimization, the mechanics of reading a query
execution plan can’t be underestimated. Fortunately, SQL Server exposes the internals of query execu-
tion in several ways: graphically, with text showplans, and with XML, and makes them relatively easy to
read once they make sense.

This chapter covered the how-to of reading and working with query execution plans. The key point to
remember is that both estimated and actual query execution plans show the actual plan. The difference
is that the estimated plan doesn’t perform the query, so it can’t show the actual row count in the con-
nector’s properties.
The next chapter transitions into the whys and wherefores of query execution plans and how to manipu-
late them with indexes — an execution plan one-two punch.
1320
www.getcoolebook.com
Nielsen c64.tex V4 - 07/21/2009 4:08pm Page 1321
Indexing Strategies
IN THIS CHAPTER
Indexing for improving
performance
Interpreting query execution
plans
A database strategy for
improving performance
M
y son Dave and I love to watch ‘‘MythBusters.’’ Even if we know Adam
and Jamie aren’t going to get the pig’s head to blow up, it’s a blast to
see them try.
If there’s any aspect of SQL Server populated with misconceptions (or shall I say,
‘‘mythconceptions’’), it’s indexing — and that’s unfortunate, because sound indexing
isn’t all that complicated.
My Smart Database Design Seminar is based on the notion (described in
Chapter 2) that an elegant physical schema lends itself to writing great set-based
queries that respond well to indexing. It’s the theory I use when I design a
database and when I go on a performance-tuning and optimization consulting job.
One aspect of Smart Database Design is that no layer can overcome deficiencies in
lower layers, i.e., no index will solve an inappropriate cursor and a sorry database

schema.
Nulltheless, indexes are at the heart of SQL Server performance; they are the
bridge from the question to the data — from the query to the schema.
Indexes are so critical to SQL Server performance that I’ve spent two months
longer than my writing schedule allowed to explain how to think about indexes,
work through the twelve query paths, and present a solid indexing strategy.
Zen and the Art of Indexing
Right up front, here’s my secret to designing effective indexes: When I’m index-
ing, in my mind’s eye I don’t see tables and indexes, I see only indexes. Some
indexes have more data attached to the leaf level than other indexes, but there are
only indexes. When indexing, there’s no such thing as a table in SQL Server.
1321
www.getcoolebook.com