2010 ami levin. sql server implements three different physical operators to perform joins. in this...

2010

PHYSICAL JOIN OPERATORS

Ami Levin

SESSION GOALS• SQL Server implements three different physical

operators to perform joins. In this session we will see how each of these three operators work, its advantages and challenges.

• We will try to understand the logic behind the optimizer’s decisions on which operator to use for various joins using (semi) real life examples and see examples about how to avoid common pitfalls.

EQUI-INNER-JOINSELECT X,Y,Z…FROM [Table1] INNER JOIN [Table2]

ON [Table1].[C1] = [Table2].[C1]

AND [Table1].[C2] = [Table2].[C2]WHERE …

NEXT TIME• Outer Joins• Non Equi-Joins• Logical Processing Order• NULL Value Issues• Join Parallelism• Partitioned Joins

WHAT IS A JOIN

NESTED LOOPSFetch next row from blue input

No More Rows?Quit

Find matching rows in red input

False

True

Start

CONSIDERATIONS• “Outer Loop” = The Number of Iterations• At Least One Small Input Preferable

• “Inner Operation” = Work for Each Iteration• Index/Table Scan• Index Seek with Lookup• Covering Index Seek

FOREIGN KEY JOINS• Joins Parents and Childs• Most Common Relationship is One-to-Many• Parent IS Indexed Primary Key or Unique• Indexing Foreign Keys Enables Efficient Use

of Nested Loops

NESTED LOOPS

DEMO

MERG

E

Fetch next row from blue input

Fetch next row from red input

True

Start

Rows Match?

False

Quit No More Rows?

False

True

CONSIDERATIONS• Input Must be Pre-Sorted• By All Join Expression(s)• Pre-Sorted in Plan, not necessarily in DB…

• Immediate & Sorted Match Outputs• FASTFIRSTROW Hint

• Very Efficient and Simple Operator

MERGE

DEMO

Fetch next row from blue input

No more rows?

Fetch next row from red input

False

Start

Apply “hash” function

Place row in “hash” bucket

No more rows?

Apply “hash” function

False

True

True

Probe bucket for matching rows

Quit

HASH- MATCH

CONSIDERATIONS• Hash Function Selection• CPU, Memory and potential I/O Overhead• No Sorting Whatsoever• Probing Costs Not Revealed• May Indicate Sub-Optimal Indexing

HASH MATCH

DEMO

CONCLUSION Nested Loops Merge Hash

Good choice when Small outer inputInner input indexed

Pre-sorted inputsSorting required

Very large inputsNot well indexed

CPU consumption Low Low*Unless requires sorting High

Memory usage Low Low*Unless requires sorting High

Logical reads High Low Low* ‘Hidden’ cost of probes

Output matches Fast Fast Slow

FOR MORE INFORMATION• Books On Line• Microsoft White Papers• “SQL Server 2008 Internals”• Kalen Delaney, Kimberly L.Tripp and more…

• Craig Freedman’s MSDN Blog• http://blogs.msdn.com/craigfr/about.aspx

PHYSICAL JOIN OPERATORS

Q&A?

THANK YOU

COMING UP…P/X001Designing High Scale OLTP systemsThomas KejserP/L001TSQL Techniques – Why and how to tune a routineDave BallantyneP/L002Implementing Common Business Calculations in DAXChris WebbP/L005Consolidating data collection with SQLDIAG and analysing it all with SQLNexus Christian BoltonP/T007Introduction to SQL Modelling Services Robert Hogg

#SQLBITS