Introduction to reading execution plans

Introduction to reading execution plans
Execution Plans … where do I start? Introduction to reading execution plans Hugo Kornelis, JuTi Holding BV

OregonSQL User Group www.OregonSQL.org
Meetings Every 2nd Wednesday, 6:00PM – 9:00PM 1515 SW 5th Ave, Suite 900, Portland

Support Our Sponsors

Hugo Kornelis I make SQL Server Fast

Hugo Kornelis I make SQLServerFast.com
Execution Plan Reference: Detailed description of all operators and other relevant information Other content Blog: Articles Longer, even more detailed in-depth information Resources Deck and demo for this session (and others)

Hugo Kornelis I make SQLServerFast.com I do other community things
Technical editor for various books SQL Server Execution Plans, 3rd edition (Free download at Lots of other things 11 years MVP (2006 – 2016, SQL Server/Data Platform)

I work Independent database consultant Will do (almost) anything for money

I work Contact details

Execution plans … Where do I start?
Agenda Why should I care? Where can I find them? How to read them? Properties Most important operators

Execution plans … Why should I care?
Traditional “third generation” (procedural) programming languages Step by step description of what the computer should do Use loops to deal with collections Load first element into memory Do actions Read next element Repeat until done Algorithms chosen by the developer When code runs slow, blame the developer (Makes sense, the developer wrote the code, the developer can fix it)

SQL (Structured Query Language) Concise description of requested final result “Set based” – result described by applying set logic to input collections Logically defined as “all at once” In reality, computer still only processes one element at a time SQL Server “translates” set-based logic to one-step-at-a-time processing This is done by the “query optimizer” Algorithms chosen by the query optimizer When code runs slow, blame the developer / DBA (Yes, we can pass blame to the query optimizer … but we still need to fix it!)

Microsoft SQL Server – Transact-SQL (T-SQL) Mixes set-based queries with procedural code Multiple causes of slowness Lots of procedural code Typical fix: rewrite the procedural code as set-based code SQL Server heavily optimized towards set-based code Single query slow Apparently the optimizer picked a slow algorithm Execution plan shows what algorithms were chosen And THAT is why we care!

Execution plans … Where can I find them?
Finding “problem plans” on a production server Plan cache Query Store Extended events / trace Monitoring tools Various DMVs Not in scope for this session

Finding “problem plans” on a production server Finding plan for a specific query DEMO

Finding “problem plans” on a production server Finding plan for a specific query Estimated execution plan Query optimizer compiles plan Query NOT executed Plan shown is how it will be executed (With some exceptions) Should (in my opinion) have been called “execution plan”

Finding “problem plans” on a production server Finding plan for a specific query Estimated execution plan Actual execution plan Query optimizer compiles plan Query IS executed, some run-time statistics added to plan Plan shown is same as estimated plan (Usually) … but with those run-time statistics added Should (in my opinion) have been called “execution plan with run-time statistics”

Finding “problem plans” on a production server Finding plan for a specific query Estimated execution plan Actual execution plan Live Query Statistics Query optimizer compiles plan Plan shown as execution starts Run-time statistics continuously updated during execution Numbers compared to estimates Beware of effects of wrong estimates! Mostly useful for long running queries

Execution plans … How to read them?
Elements within an execution plan Icons (operators) Small programs that “do something” Arrows (data flows) Not actual elements of the plan

Elements within an execution plan Icons (operators) Small programs that “do something” Exactly three functions Initialize() Prepare to do work Can also be used to reinitialize “restart from the top” Some parameters can be changed when reinitialized

Elements within an execution plan Icons (operators) Small programs that “do something” Exactly three functions Initialize() GetNext() Return a single row to calling operator How this row is produced depends on the specific operator Often involves calling GetNext() on other operators

Elements within an execution plan Icons (operators) Small programs that “do something” Exactly three functions Initialize() GetNext() Close() Clear up memory used etc Called once per operator, when query has finished

Elements within an execution plan Icons (operators) Small programs that “do something” Exactly three functions Overloaded term, may be confusing Operator = generic type of operator “The Filter operator applies a predicate to its input rows and returns only rows for which the predicate evaluates to True”. Operator = instance of an operator (type) within a plan “I don’t understand why a plan with three Filter operators was used for this query”.

Elements within an execution plan Icons (operators) Arrows (data flows) Not actual elements of the plan Represent which operators call which other operators Each operator is called by, and returns rows to, exactly one operator Calling operator is called the parent operator Called operator is called the child operator

Elements within an execution plan Icons (operators) Arrows (data flows) Not actual elements of the plan Represent which operators call which other operators Each operator is called by, and returns rows to, exactly one operator Each operators calls zero, one, or more child operators Execution plan is basically a “tree” (graph theory) Hence operators within a plan are often called “nodes”

Common misunderstandings Cost percentages Looks deceptively easy … but often is just deceptive Always based on estimated cost (even in actual execution plan!) Incorrect if estimated row count is wrong Can also be off for other reasons E.g. hardware assumptions DEMO

Common misunderstandings Cost percentages Read direction Left to right? Right to left? Something else? GetNext() GetNext()  ? GetNext()  ?

Execution plans … Properties
(Graphical) execution plan Properties

DEMO

How to access properties? Hover over an icon Subset of properties for that operator Chosen by Microsoft … not always best selection

How to access properties? Hover over an icon Hover over an arrow Even smaller subset of properties for operator to the right Focuses only on amount of data produced by that operator

How to access properties? Hover over an icon Hover over an arrow Right-click icon, select “Properties” Properties window shows all properties Bit harder to access When you leave the properties window open, clicking on an operator in the plan changes the window to the operator you clicked (This makes accessing the data less hard)

How to access properties? Top-left operator Not a “real” operator (represents client requesting rows) Has lots of properties that relate to the plan as a whole DEMO

How to access properties? Top-left operator Other operators Properties apply to that operator Some properties can cause significant behavior changes!

How to access properties? Top-left operator Other operators What do those properties mean? Not in scope for this session Many are fairly self-explanatory Resource: (Currently still far from complete)

Execution plans … Most important operators
Each operator has its own, distinct task As of SQL Server 2017, 67 different operators exist Only small subset (the most important ones) in scope for this session Operators that read data Read data from a table, or from an index These operators do NOT have a child operator Different operators and patterns for different use cases Operators that combine data Read data from two or more child operators Combine these inputs to form a single output stream Different algorithms, with vastly different performance characteristics

Operators that read data Scan operators Read all rows from a table (or index) [but only when called often enough!] DEMO

Operators that read data Scan operators Read all rows from a table (or index) Different access methods Unordered Always possible Ordered Not for table (heap) Not for in-memory hash index Not for columnstore index Check properties to find method used

Operators that read data Scan operators Read all rows from a table (or index) Different access methods Often filters rows Predicate property Called “pushed down” search predicate Used to reduce workload as early as possible Rows are still read!! Just not passed to parent DEMO

Operators that read data Scan operators Seek operators Use index structure to find specific rows Different access methods Singleton lookup: find one specific row Not for table (heap) Not for columnstore index Not for non-unique search values Range seek: find range of rows Limited for in-memory hash index

Operators that read data Scan operators Seek operators Lookup operators Similar to seek (singleton lookup) Nonclustered index used (elsewhere in plan) to find rows to process Lookup then reads rest of data Key Lookup  clustered index RID Lookup  table (heap) May be candidate for creating a covering index Optimizer may choose scan instead of seek + lookup when estimated number of rows is too high

Operators that read data Operators that combine data Join operators Combine two inputs Multiple logical operations Inner join  similar to INNER JOIN in SQL Left, right, full outer join  similar to OUTER JOIN in SQL Left, right semi join  similar to EXISTS in SQL Left, right anti semi join  similar to NOT EXISTS in SQL

Operators that read data Operators that combine data Join operators Combine two inputs Multiple logical operations Multiple physical operators Nested Loops Merge Join Hash Join Adaptive Join

Operators that read data Operators that combine data Join operators Combine two inputs Multiple logical operations Multiple physical operators Other combining operators Combine two or more inputs Concatenation  similar to UNION ALL in SQL Sequence  one or more preparation steps, final input returns results Switch  outdated, hardly ever used anymore Not in scope

Operators that join data Nested Loops Initializes and reads top (“outer”) input once ... until “done” (usually end of input) For each row from top input: Initializes and reads bottom (“inner”) input … until “done” (usually end of input) Two variations Join Predicate: Bottom always returns same data, operator checks for matches Outer References: Value from top input pushed into bottom to return only “correct” rows

Operators that join data Nested Loops Initializes and reads top (“outer”) input once ... until “done” (usually end of input) For each row from top input: Initializes and reads bottom (“inner”) input … until “done” (usually end of input) Two variations Cheap or expensive? How many rows in top input? How expensive is one execution of bottom input? Multiply for total cost Ideal case: small top, cheap bottom Scales very bad if top input is underestimated

Operators that join data Nested Loops Merge Join Initializes and reads both inputs once… until “done” (usually end of input) Requires both inputs to be sorted by join column(s) Uses the guaranteed order to efficiently merge the two inputs Two variations Depending on relationship between input streams One to many Very effective Only used if optimizer can guarantee one to many relationship

Operators that join data Nested Loops Merge Join Initializes and reads both inputs once… until “done” (usually end of input) Requires both inputs to be sorted by join column(s) Uses the guaranteed order to efficiently merge the two inputs Two variations Depending on relationship between input streams One to many Many to many Writes rows from bottom input to temporary table Temporary table used to re-read same rows if top has duplicate

Operators that join data Nested Loops Merge Join Initializes and reads both inputs once… until “done” (usually end of input) Requires both inputs to be sorted by join column(s) Uses the guaranteed order to efficiently merge the two inputs Two variations Cheap or expensive? Operator itself is very cheap Cost of ensuring that data is sorted Sort operators are very expensive Ordered vs unordered scans Which operators preserve order?

Operators that join data Nested Loops Merge Join Initializes and reads both inputs once… until “done” (usually end of input) Requires both inputs to be sorted by join column(s) Uses the guaranteed order to efficiently merge the two inputs Two variations Cheap or expensive? Operator itself is very cheap Cost of ensuring that data is sorted Huge extra overhead for many to many

Operators that join data Nested Loops Merge Join Hash Match Initializes and reads top (“build”) input once… until end of input All rows are stored in “hash table” in memory Hash table = conceptually thousands of small tables (“buckets”) Hash (computed number) used to find which bucket to use

Operators that join data Nested Loops Merge Join Hash Match Initializes and reads top (“build”) input once… until end of input Initializes and reads bottom (“probe”) input… until “done” (usually end of input) Searches for matching rows in hash table Only needs to search a single bucket (based on hash)

Operators that join data Nested Loops Merge Join Hash Match Initializes and reads top (“build”) input once… until end of input Initializes and reads bottom (“probe”) input… until “done” (usually end of input) Cheap or expensive? High CPU usage High memory usage Spills to tempdb when actual memory exceeds requested (estimated) memory

Operators that join data Nested Loops Merge Join Hash Match Adaptive Join Run-time choice between nested loops or hash match algorithm Initializes and reads top (“build”) input once… until end of input All rows are stored in “hash table” in memory Counts actual number of rows in hash table

Operators that join data Nested Loops Merge Join Hash Match Adaptive Join Run-time choice between nested loops or hash match algorithm Initializes and reads top (“build”) input once… until end of input Number of rows > threshold? Choose hash match algorithm Initializes and reads second (“probe”) input Does not use third input at all

Operators that join data Nested Loops Merge Join Hash Match Adaptive Join Run-time choice between nested loops or hash match algorithm Initializes and reads top (“build”) input once… until end of input Number of rows > threshold? Number of rows < threshold? Choose nested loops algorithm Initializes and reads third (“inner”) input once for each row in the hash table Does not use second input at all

Operators that join data Nested Loops Merge Join Hash Match Adaptive Join Run-time choice between nested loops or hash match algorithm Initializes and reads top (“build”) input once… until end of input Number of rows > threshold? Number of rows < threshold? Cheap or expensive? “Best of both worlds” for nested loops or hash match Small overhead Less risk of running out of control

Operators that join data Nested Loops Merge Join Hash Match Adaptive Join Run-time choice between nested loops or hash match algorithm Initializes and reads top (“build”) input once… until end of input Number of rows > threshold? Number of rows < threshold? Cheap or expensive? Only SQL Server 2017 (and higher) Requires “batch mode”

Twitter: @Hugo_Kornelis
T H E E N D Questions?

Support Our Sponsors

Twitter: @Hugo_Kornelis
Questions? T H E E N D

Introduction to reading execution plans

Similar presentations

Presentation on theme: "Introduction to reading execution plans"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Introduction to reading execution plans

Similar presentations

Presentation on theme: "Introduction to reading execution plans"— Presentation transcript:

Similar presentations

About project

Feedback