Physical join operators ISUG 105
-
Upload
sqlservercoil -
Category
Documents
-
view
909 -
download
2
description
Transcript of Physical join operators ISUG 105
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-JOIN
SELECT 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
MER
GE
Fetch next row from blue input
Fetch next row from red input
True
Start
Rows Match?
False
QuitNo 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