Diving into Query Execution Plans ED POLLACK AUTOTASK CORPORATION DATABASE OPTIMIZATION ENGINEER

How is a Query Processed? PARSING: The SQL statement is broken down into logical pieces: keywords, objects, operators, etc…and is checked for syntax errors. BINDING: Object names are checked against system views. A query tree is built with this data, creating an ordered list of steps that are needed to get from input to output. AKA: algebrizer. OPTIMIZATION: The query optimizer analyzes different ways to process the query and chooses the best one found. The result is an execution plan. EXECUTION: The query is executed by the relational engine based on the results of the optimizer.

What are Query Execution Plans? Graphical step-by-step depiction of how a query is executed (right-to-left). Lots of useful detail! Combine with IO & time statistics to get a thorough look at the resources consumed by a query. Steps are illustrated with subtree cost (what’s this!?)

What Does the Query Optimizer Do? Creates a list of many possible execution plans. Analyzes resources required and estimates cost. Follows a set structure of search paths. Uses transformation rules to generate plans. Statistics are key to this process. Chooses the best plan found in the time allotted. May not be the best plan possible! SQL Example: Turning on & using execution plans.

Table Access Table Scan This is a complete scan through a heap. Tables should always have a clustered index - if you see this, beware! Clustered Index Scan This is a complete scan of a table with a clustered index. While inefficient, this can be good for a return of a large % of the table, or in the case of a very small table. Clustered Index Seek/Non Clustered Index Seek Data is read by using an index on the target table. Indexes are stored as a b-tree, so the effort of a seek vs. a scan is significantly less. Key Lookup /RID Lookup When columns are selected that are not included in the index, a lookup to the table is performed to get that data. SQL Example: Table Access

Joins Hash Match Often used where a small table is joined to a larger table. A hash table is created using the smaller table, and the larger table is matched via the hash table row-by-row. This temporary hash table is stored in TempDB. Works well on unsorted/unindexed inputs. Nested Loops One set of data is compared to the other, row-by-row, until all rows have been matched. Efficient for small data sets or when one input is indexed and the other isn’t (and isn’t too large). Merge Join Only very works well on sorted data. Since both sets are sorted, they can be matched directly with each other quickly. This can be inefficient if somehow used on unsorted data. SQL Example: Types of joins

Other Basic Elements (part 1) Compute Scalar Performs a basic scalar operation on data, such as DATEPART, +, ROUND, or LEFT Sort Sorts input, either by an ORDER BY, or to complete a join Filter Scans input and checks a condition, such as via a HAVING or WHERE clause. Concatenation Used to combine 2 data sets, usually via UNION ALL. Top Returns the Top N rows from a data set. Constant Scan Introduces a fixed number of scalar rows into the query so that future operations can be completed. Can also replace trivial query sections.

Other Basic Elements (part 2) Stream Aggregate Used when we GROUP or PARTITION data to group by a specific column or columns. Spools: Eager & Lazy Temporary data storage in TempDB for rows that may be needed again or to separate sensitive data from the underlying data storage. Eager: spools all data at the start; Lazy: spools only rows of data as needed. Insert, Update, Delete, Select Self-explanatory : )

Execution Plan & IO Display Options SHOWPLAN_ALL SHOWPLAN_TEXT STATISTICS PROFILE STATISTICS IO STATISTICS TIME SHOWPLAN_XML (in trace) STATISTICS XML (in trace) SQL Example: Display Options

Additional Optimizer Notes Plan Cache Execution plans are saved in memory for reuse in the future. Allow frequently executed queries to be executed without the need for optimization each time. Plans are removed due to age, memory, lack of use, or changes in statistics or table structure. Query hash & plan reuse Execution plans can change at runtime (Recompile). Actual vs. estimated execution plans. SQL Example: Insight into query optimization.

Hints Query hints can be used in writing queries to tell the optimizer to modify joins, join orders, locking mechanisms, query plans, default data, etc… Examples include: WITH (NOLOCK) OPTIMIZE = ‘blue’ OPTION (MAXDOP 1) OPTION (FAST 10) OPTION (HASH JOIN) Hints should be used rarely as they constrain the query optimizer. Frequent usage of hints can be indicative of a much more severe problem Very bad hints can render a query unexecutable!

Questions ?????

Conclusion & Thank You! For additional reading, please see: SQL Server Execution Plans: Grant Fritchey: execution-plans.pdf execution-plans.pdf Inside the SQL Server Query Optimizer: Benjamin Nevarez: sql-server-query-optimizer/ sql-server-query-optimizer/ SQL Server Central: SQL Shack: Also, keep an eye out for SQL Saturday Albany in July, 2016! Contact info: