Execution Plans Demystified Ernest Libertucci Execution Plans Demystified

Presenter Info Senior Database Engineer 17+ Years Using SQL Server Database administration, SSIS, Hadoop, etc Thank you to our sponsers!

Execution Plans – What are they? An execution plan (or query plan) is a description of the operations the SQL Server engine will use to perform a given task, along with the metrics involved in this decision making process.

Why should we care? Can answer questions including: Why is my query so slow? Is that index I created being used? Why is TempDB growing? Where was I last night? (Okay, maybe not that one)

Goal – Avoid becoming this:

Permissions Required SHOWPLAN permission is required (database-level) for all databases involved in the query.

How do we see them? SSMS Menu. CTRL + L (Show Estimated) CTRL + M (Include Actual) SET SHOWPLAN_XML ON

Indexes

Types of Indexes Clustered – Logical ordering of data (Page splits can change physical order). Data pages are the leaf nodes, so the table becomes this index. Tables without a clustered index are called a heap. Non-clustered – One or more columns. Nodes contain pointer to the row data stored in the clustered index (or heap). Columnstore. Filtered.

Statistics

Statistics Details Cardinality: Uniqueness of Data values (Example: Countries would have 193 distinct values). Cardinality Estimates refer to the engines ‘belief’ about a column’s distribution. Contributes greatly to the choices of operators used in an execution plan.

A day in the life of a Query – Part 1

A day in the life of a Query – Part 2

A day in the life of a Query – Part 3

Query Optimizer Software that analyzes potential execution plans for a given query and chooses which one to execute. Cost-based, but will choose the best plan it can within a quantum. Parses the query, creating a logical tree of operations. Using this tree, the QO examines some potential ways to satisfy a query and then picks the lowest cost one.

Operators Table/Clustered Index Scan Index Seek Sort Key/Bookmark Lookup Aggregates Scalar Data Modification

Join Operators – Nested Loop In general, better for smaller data inputs. Cost A * B

Join Operators – Merge Join Join two sorted inputs (Sort operator or Index) Ideal for large range scans where both sides are indexed. Cost A + B

Join Operators – Hash Match Build a hash table for both inputs, then look for matching. Typically chosen when at least 1 input is large. Image: By Jorge Stolfi - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=6471238

Suspicious Things Seek (go to value) vs Scan (read entire table/index) SARgable predicates (Search ARGumentable) { f(col1) = value vs col1 = f(value) } Implicit conversion { ex: column1 = ‘5’ when column1 is integer } Statistics {Estimated widely different from Actual }

Considerations Give the Query Optimizer Information Constraints, Keys (Primary/Foreign), Nullability Avoid Implicit Conversion Database Compatibility Level Querytraceon hint (9481 or 2312) 9481: Use 2012 QO on a later version of sql server 2312: Use 2014 QO on a 2012 or lower set database (SQL 2014+) https://support.microsoft.com/en-us/help/2801413/enable-plan-affecting-sql-server-query-optimizer-behavior-that-can-be

Query Store (2016+) Plan, Runtime stats, wait stores.

Automatic Plan Correction (SQL 2017) Apply previous plan instead of a regressed one. Note: “current” keyword syntax since 2012.

Other Things of Note ™ Live statistics Query Optimizer (2014) QO Fixes

References/Further Information SQL Server Execution Plans (3rd Ed) – Grant Fritchey Execution Plan Reference https://sqlserverfast.com/epr Sp_WhoIsActive – Adam Machanic SentryOne Plan Explorer

Thank you!