Physical join operators ISUG 105

791 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
791
On SlideShare
0
From Embeds
0
Number of Embeds
123
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Physical join operators ISUG 105

  1. 1. Physical Join Operators<br />2010<br />Ami Levin<br />
  2. 2. Session Goals<br />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. <br />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.<br />
  3. 3. Equi-Inner-Join<br />SELECTX,Y,Z…<br />FROM[Table1] INNER JOIN [Table2]<br />ON [Table1].[C1] = [Table2].[C1]<br />AND [Table1].[C2] = [Table2].[C2]<br />WHERE…<br />
  4. 4. Next Time<br />Outer Joins<br />Non Equi-Joins<br />Logical Processing Order<br />NULL Value Issues<br />Join Parallelism<br />Partitioned Joins<br />
  5. 5. What Is a Join<br />
  6. 6. Nested Loops<br />Fetch next row from blue input<br />Start<br />No More Rows?<br />Quit<br />True<br />False<br />Find matching rows in red input<br />
  7. 7. Considerations<br />“Outer Loop” = The Number of Iterations<br />At Least One Small Input Preferable<br />“Inner Operation” = Work for Each Iteration<br />Index/Table Scan<br />Index Seek with Lookup<br />Covering Index Seek<br />
  8. 8. Foreign Key Joins<br />Joins Parents and Childs<br />Most Common Relationship is One-to-Many<br />Parent ISIndexed Primary Key or Unique<br />Indexing Foreign Keys Enables Efficient Use of Nested Loops<br />
  9. 9. Nested Loops<br />DEMO<br />
  10. 10. Fetch next row from blue input<br />Start<br />No More Rows?<br />Quit<br />True<br />False<br />Merge<br />Fetch next row from red input<br />Rows Match?<br />True<br />False<br />
  11. 11. Considerations<br />Input Must be Pre-Sorted<br />By All Join Expression(s)<br />Pre-Sorted in Plan, not necessarily in DB…<br />Immediate& Sorted Match Outputs<br />FASTFIRSTROW Hint<br />Very Efficient and Simple Operator<br />
  12. 12. Merge<br />DEMO<br />
  13. 13. Fetch next row from blue input<br />Fetch next row from red input<br />Start<br />No more rows?<br />No more rows?<br />True<br />True<br />False<br />False<br />Quit<br />Hash- Match<br />Apply “hash” function<br />Apply “hash” function<br />Place row in “hash” bucket<br />Probe bucket for matching rows<br />
  14. 14. Considerations<br />Hash Function Selection<br />CPU, Memory and potential I/O Overhead<br />No Sorting Whatsoever<br />Probing Costs Not Revealed<br />May Indicate Sub-Optimal Indexing<br />
  15. 15. Hash Match<br />DEMO<br />
  16. 16. Conclusion<br />
  17. 17. For More Information<br />Books On Line<br />Microsoft White Papers<br />“SQL Server 2008 Internals”<br />Kalen Delaney, Kimberly L.Tripp and more…<br />Craig Freedman’s MSDN Blog<br />http://blogs.msdn.com/craigfr/about.aspx<br />
  18. 18. Physical Join Operators<br />Q&A?<br />
  19. 19. Thank You<br />
  20. 20. Coming up…<br />P/X001<br />Designing High Scale OLTP systems<br />Thomas Kejser<br />P/L001<br />TSQL Techniques – Why and how to tune a routine<br />Dave Ballantyne<br />P/L002<br />Implementing Common Business Calculations in DAX<br />Chris Webb<br />P/L005<br />Consolidating data collection with SQLDIAG and analysing it all with SQLNexusChristian Bolton<br />P/T007<br />Introduction to SQL Modelling Services <br />Robert Hogg<br />#SQLBITS<br />

×