One of the most useful tools in SQL Server for analyzing and troubleshooting a query’s performance is the execution plan. An execution plan can tell you how the database engine intends to execute a query, as determined by the query optimizer, or how the database engine actually executed the query.
In most cases, the estimated plan and actual plan are one in the same. The optimizer generates the plan and hands the plan off to the engine, which uses it executes the query. When you view the actual plan, you’re essentially looking at the estimated plan generated by the optimizer, with a few runtime statistics added in for good measure.
The actual plan will differ from estimated plan only if something happens in between the estimating and processing operations that forces SQL Server to recompile the associated query and the optimizer to produce a completely new plan. For example, someone might modify an underlying table or recompile a stored procedure.
The execution plan breaks the execution process down into hierarchical steps that show each operation needed to access the target data or perform computations against that data. For each operation, the execution plan provides detailed information such as the operation type, output columns, number of rows, and estimated CPU and I/O usage. The details also include the estimated cost of an operation, as determined by the optimizer, relative to the rest of the query’s operations.
SQL Server provides a number of methods for accessing a query’s execution plan, ranging from clicking a button in SQL Server Management Studio (SSMS) to setting up extended events that capture execution plans based on specific criteria. In this article, we look at the various methods for accessing execution plans and provide some of the necessary basics for how to find the information they provide.
Using SSMS to access execution plansThe simplest and quickest way to access a query’s execution plan is to use SSMS to view a graphical representation of either the estimated or actual plan. To demonstrate how this works, let’s start with the following SELECT statement, which joins two tables in the AdventureWorks2014 database (installed on a local instance of SQL Server 2014):
SELECT sh.SalesOrderID, sh.CustomerID, sh.OrderDate, sd.ProductID, sd.LineTotal FROM Sales.SalesOrderHeader sh JOIN Sales.SalesOrderDetail sd ON sh.SalesOrderID = sd.SalesOrderID WHERE sd.LineTotal BETWEEN 1000 AND 1500;The SELECT statement simply joins the SalesOrderHeader table with the SalesOrderDetail table and returns a range of values based on the LineTotal column in the SalesOrderDetail table. The LineTotal column is a computed column that derives its values from the UnitPrice , UnitPriceDiscount , and OrderQty columns in the same table.
To display a query’s execution plan, you must first type (or copy-and-paste) the query into a new query tab in SSMS or open a T-SQL script file that contains the query. You can also type the query into an existing tab that contains other queries, but if you do, you must highlight the query before trying to view the plan, just as you would if running a single T-SQL statement from a group of statements.
With the query in place, and selected if necessary, click the Display Estimated Execution Plan button on the SSMS toolbar to view its estimated plan, or click the Include Actual Execution Plan button to view the actual plan.
The Display Estimated Execution Plan button is a one-time event, which means you must click it each time you want to view the estimated plan for a selected query. If you select this option, the database engine generates the plan without running the query.
The Include Actual Execution Plan button is a toggle that is either on or off. If on, the database engine executes the query and generates an actual plan. SSMS will continue to return the execution plan for each executed query until you explicitly toggle the button off.
Regardless of which option you choose, SSMS displays the plan on its own results tab, separate from any query results or messages. The following figure shows the execution plan after turning the Include Actual Execution Plan option on.
In this case, the actual plan displayed is the same as the estimated plan, which indicates that the optimizer likely did not generate a new plan when it came time to processing the query. More often than not, this will be the situation you’ll run into, particularly for simple queries such as our example. That said, there will be times when they differ. For example, if a table’s statistics are not current as a result of inserting data into an IDENTITY column, SQL Server will update the statistics next time you run a query against that table and then recompile the plan.
Whether you’re working with the estimated plan or the actual plan, SSMS presents the information in a similar manner, displaying a specific icon, or operator, for each operation type. The execution plan for our sample SELECT query shows five operations, but only three different types:
Merge Join: Performs a type of join, such as an inner join, left outer join, or right outer join. In this case, the operation is performing an inner join on the two data sets from the SalesOrderHeader and SalesOrderDetail tables. Clustered Index Scan: Scans a clustered index and returns all rows or only those rows specified in the WHERE clause. For the SalesOrderHeader table, the operation returns all rows. For the SalesOrderDetail table, the operation returns only those row with a LineTotal value between 1000 and 1500 . Compute Scalar: Evaluates an expression and returns a computed scalar value. In our example, both Compute Scalar operations are related to calculating the LineTotal value for each row returned by the bottom Clustered Index Scan operation.Not surprisingly, SSMS supports numerous other icons to represent the various operation types, nearly 90 at last count. You can find a list of icons in the TechNet topic Graphical Execution Plan Icons (SQL Server Management Studio) . The topic also provides links to individual descriptions of each operation.
One icon I have not mentioned and one you will not find on the TechNet list is SELECT . This is because it is not considered an operation. Rather, the icon represents the final results of the query. It sits at the top of the plan hierarchy and provides information about the query as a whole.
We’ll get into how to view more details about the SELECT icon and the other nodes shortly, but first let’s take a step back to look at the plan as a whole because this is where things can sometimes get confusing, especially if you’re new to execution plans.
When reading an execution plan, you gene