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

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 ope

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

Ibelieve 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 sevsev-eral 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

■ 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?

There’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:

■ 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 = 757using an index seek operation against the[WorkOrder.IX_WorkOrder_

ProductID]non-clustered index

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, theShowplanoptions 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 SHOWPLANmust be the only

statement in the batch

SET SHOWPLANcomes is three flavors:ALL,TEXT, andXML:

■ SHOWPLAN_ALLdisplays 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_TEXTis very similar toSHOWPLAN_ALLexcept that the executing statement and the operations are in separate result sets and only thestmt text(first column) is displayed

TheSHOWPLAN_TEXToption, along with theSET STATISTICSoptions, 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_XMLdisplays 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_XMLdisplays the Query Optimizer optimization level,

or the reason why the Query Optimizer returned this execution plan For the XML version of

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 theSET STATISTICS PROFILE ONcommand, which

exe-cutes the query and then supplies the same detail asSHOWPLAN_ALLwith the addition of actual row

counts and execution counts This is the result set equivalent of theSHOW ACTUALexecution 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.sqlplanfile 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 aCROSS APPLYto

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

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

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 theWHEREclause 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 theORDER 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.

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

Indexing Strategies

IN THIS CHAPTER Indexing for improving performance

Interpreting query execution plans

A database strategy for improving performance

My 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