30.06.2013 Views

SQL Server Execution Plans - Red Gate Software

SQL Server Execution Plans - Red Gate Software

SQL Server Execution Plans - Red Gate Software

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

UPDATE statements<br />

Chapter 2: Graphical <strong>Execution</strong> <strong>Plans</strong> for Basic Queries<br />

UPDATE statements are also against one table at a time. Depending on the structure of the<br />

table, and the values to be updated, the impact on the execution plan could be as severe as<br />

that shown above for the INSERT query. Consider the UPDATE statement in Listing 2.16.<br />

UPDATE [Person].[Address]<br />

SET [City] = 'Munro',<br />

[ModifiedDate] = GETDATE()<br />

WHERE [City] = 'Monroe' ;<br />

Listing 2.16<br />

Figure 2.36 shows the estimated execution plan.<br />

Figure 2.36<br />

Let's begin reading this execution plan in the physical operation order, from right to<br />

left. The first operator is a NonClustered Index Scan, which retrieves all of the necessary<br />

rows from a non-clustered index, scanning through them, one row at a time. This is<br />

not particularly efficient and should be a flag to you that perhaps the table needs better<br />

indexes to speed performance. The purpose of this operator is to identify all the rows<br />

WHERE [City] = 'Monroe', and then send them to the next operator.<br />

The next operator is Top. In an execution plan for an UPDATE statement, the Top<br />

operator enforces row count limits, if there are any. In this case, no limits were enforced<br />

because the TOP clause was not used in the UPDATE query as you can see in Listing 2.16.<br />

112

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!