20
2010 PHYSICAL JOIN OPERATORS Ami Levin

Physical join operators ISUG 105

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Physical join operators ISUG 105

2010

PHYSICAL JOIN OPERATORS

Ami Levin

Page 2: Physical join operators ISUG 105

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.

Page 3: Physical join operators ISUG 105

EQUI-INNER-JOIN

SELECT X,Y,Z…FROM [Table1] INNER JOIN [Table2]

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

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

Page 4: Physical join operators ISUG 105

NEXT TIME

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

Page 5: Physical join operators ISUG 105

WHAT IS A JOIN

Page 6: Physical join operators ISUG 105

NESTED LOOPSFetch next row from blue input

No More Rows?

Quit

Find matching rows in red input

False

True

Start

Page 7: Physical join operators ISUG 105

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

Page 8: Physical join operators ISUG 105

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

Page 9: Physical join operators ISUG 105

NESTED LOOPS

DEMO

Page 10: Physical join operators ISUG 105

MER

GE

Fetch next row from blue input

Fetch next row from red input

True

Start

Rows Match?

False

QuitNo More Rows?

False

True

Page 11: Physical join operators ISUG 105

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

Page 12: Physical join operators ISUG 105

MERGE

DEMO

Page 13: Physical join operators ISUG 105

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

Page 14: Physical join operators ISUG 105

CONSIDERATIONS

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

Page 15: Physical join operators ISUG 105

HASH MATCH

DEMO

Page 16: Physical join operators ISUG 105

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

Page 17: Physical join operators ISUG 105

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

Page 18: Physical join operators ISUG 105

PHYSICAL JOIN OPERATORS

Q&A?

Page 19: Physical join operators ISUG 105

THANK YOU

Page 20: Physical join operators ISUG 105

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