Successfully reported this slideshow.
Ami Levin, SolidQPresented to the Silicon Valley SQL Server User Group, April 2013Nesting Merged Hash LoopsAmi LevinCTO, D...
Session GoalsSQL Server uses three physical join operators:Nested loops, Merge, and Hash Match.In this session we will:• S...
Not This Time• Outer joins• Non equi-joins• Logical processing order• NULL issues• Join parallelism• Partitioned joins• …3
Equi-Inner-JoinSELECT Foo, Bar, ...FROM T1 INNER JOIN T2ON T1.C1 = T2.C1AND T1.C2 = T2.C2AND ...WHERE ...4
Visual Join Simulator5
Nested Loops6Fetch next rowfrom blue inputRowexistsQuitFind matchingrows in red inputTrueFalseStart?
Nested Loops I• Outer loop determines number of iterations• At least one input should be (relatively) small• Inner operati...
• Data pages may be accessed repeatedly• Risky a-sequential page access path• Output of matching row sets is fast• Unorder...
Nested Loopswith Foreign Key Joins• Foreign keys join parent and child• Most common relationship is one-to-many• Often par...
Nested Loops10
Merge11Fetch next rowfrom blue inputRowexistsQuitFetch next rowfrom red inputTrueFalseStartRowsmatchTrueFalse? ?
Merge I• Inputs must be sorted prior to merge• Sorted by (all?) join expression(s)• Pre-sorted in plan, but not necessaril...
Merge II• Residual predicates• Fast, ordered and grouped output• Physical resources• CPU Very low• Physical IO Very low• M...
Merge14
Hash Match - Phase I (Build)15Fetch next rowfrom blue inputRowexistsPhase IIApply hashfunctionTrueFalseStart?
Hash Match - Phase II (Probe)16Fetch next rowfrom red inputRowexistsQuitApply hashfunctionTrueFalsePhase I?
• Hash function selection• Extremely complex• CPU intensive• Build and probe costs are hidden• Do not constitute logical r...
• In memory hash joinGrace hash joinRecursive hash join• Hash bailout• Hash warnings event class• Update Statistics• Add m...
Hash Match III• May indicate sub-optimal indexing• Best for very large, non covered joins• Physical resources• CPU Very hi...
Hash Match20
Summary21Nested Loops Merge HashGood whenSmall outer inputInner input indexedPre-sorted inputsSorting neededVery large inp...
For More Information• Books on line• White papers• “Inside Microsoft SQL server” books• Craig Freedman’s blog• http://blog...
Physical Join Operators23
Complete the Evaluation Formto Win!Win a Dell Mini Netbook – every day – just for handingin your completed form. Each sess...
Thank youAmi Levin, SolidQ
Upcoming SlideShare
Loading in …5
×

Microsoft SQL Server Physical Join Operators

2,336 views

Published on

SQL Server implements three different physical operators to perform joins. In this presentation you'll see how each of these operators work plus its advantages and challenges.

You'll learn:
* The logic behind the optimizer's decisions
* Which operator to use for various joins using (semi) real life examples
* How to avoid common join-related pitfalls

Ami Levin is a Microsoft SQL Server MVP and a Mentor with SolidQ. For the past 14 years, he has been consulting, teaching, writing, and speaking about SQL Server worldwide.

Levin’s areas of expertise are data modeling, database design, T-SQL and performance tuning.

Before moving to California, he led the Israeli SQL Server user group (ISUG) and moderated the Hebrew MSDN SQL Server support forum. Ami is a regular speaker at Microsoft Tech-Ed Israel, Dev Academy, and other SQL Server conferences. He blogs at SQL Server Tuning Blog.

Published in: Technology
  • Be the first to comment

Microsoft SQL Server Physical Join Operators

  1. 1. Ami Levin, SolidQPresented to the Silicon Valley SQL Server User Group, April 2013Nesting Merged Hash LoopsAmi LevinCTO, DBSophicSQL ServerPhysical Join Operators
  2. 2. Session GoalsSQL Server uses three physical join operators:Nested loops, Merge, and Hash Match.In this session we will:• See how each of these operators work• Review their advantages and drawbacks• Understand some of the logic behind theoptimizer’s decisions on which operator to use• Learn to identify common join-related pitfalls2
  3. 3. Not This Time• Outer joins• Non equi-joins• Logical processing order• NULL issues• Join parallelism• Partitioned joins• …3
  4. 4. Equi-Inner-JoinSELECT Foo, Bar, ...FROM T1 INNER JOIN T2ON T1.C1 = T2.C1AND T1.C2 = T2.C2AND ...WHERE ...4
  5. 5. Visual Join Simulator5
  6. 6. Nested Loops6Fetch next rowfrom blue inputRowexistsQuitFind matchingrows in red inputTrueFalseStart?
  7. 7. Nested Loops I• Outer loop determines number of iterations• At least one input should be (relatively) small• Inner operation is performed for everyiteration of the outer loop• Index or table scan (naïve)• Index seek + lookup• Covering index seek• Index spool7
  8. 8. • Data pages may be accessed repeatedly• Risky a-sequential page access path• Output of matching row sets is fast• Unordered, but typically grouped• Physical resources• CPU Very low• Physical IO low to very high• Memory lowNested Loops II8
  9. 9. Nested Loopswith Foreign Key Joins• Foreign keys join parent and child• Most common relationship is one-to-many• Often parent input is significantly smaller• Parent must already be indexed• Either primary key or unique constraint• Therefore, indexing foreign keys oftenenables efficient use of nested loops9
  10. 10. Nested Loops10
  11. 11. Merge11Fetch next rowfrom blue inputRowexistsQuitFetch next rowfrom red inputTrueFalseStartRowsmatchTrueFalse? ?
  12. 12. Merge I• Inputs must be sorted prior to merge• Sorted by (all?) join expression(s)• Pre-sorted in plan, but not necessarily in DB• Preferred when sorting supports additionalplan operations• Merge join types• One to many• Many to many - requires temporary worktable12
  13. 13. Merge II• Residual predicates• Fast, ordered and grouped output• Physical resources• CPU Very low• Physical IO Very low• Memory Very low• * Excluding sorting costs13
  14. 14. Merge14
  15. 15. Hash Match - Phase I (Build)15Fetch next rowfrom blue inputRowexistsPhase IIApply hashfunctionTrueFalseStart?
  16. 16. Hash Match - Phase II (Probe)16Fetch next rowfrom red inputRowexistsQuitApply hashfunctionTrueFalsePhase I?
  17. 17. • Hash function selection• Extremely complex• CPU intensive• Build and probe costs are hidden• Do not constitute logical reads• Output of matching row sets is slow• Unordered and typically ungroupedHash Match I17
  18. 18. • In memory hash joinGrace hash joinRecursive hash join• Hash bailout• Hash warnings event class• Update Statistics• Add more RAM• Role reversalHash Match II18
  19. 19. Hash Match III• May indicate sub-optimal indexing• Best for very large, non covered joins• Physical resources• CPU Very high• Physical IO Low to very high• Memory Very high19
  20. 20. Hash Match20
  21. 21. Summary21Nested Loops Merge HashGood whenSmall outer inputInner input indexedPre-sorted inputsSorting neededVery large inputsNot well indexedCPU LowLow* Excluding sortingHighMemory LowLow* Excluding sortingHighPhysical IO Low / High Low Low / HighLogical reads High LowLow* MisleadingOutputFast, unordered,grouped*Fast, ordered,groupedSlow, unordered,ungrouped*
  22. 22. For More Information• Books on line• White papers• “Inside Microsoft SQL server” books• Craig Freedman’s blog• http://blogs.msdn.com/craigfr/about.aspx22
  23. 23. Physical Join Operators23
  24. 24. Complete the Evaluation Formto Win!Win a Dell Mini Netbook – every day – just for handingin your completed form. Each session evaluation formrepresents a chance to win.Pick up your evaluation form:• In each presentation room• Online on the PASS Summit websiteDrop off your completed form:• Near the exit of each presentation room• At the Registration desk• Online on the PASS Summit websiteSponsored by Dell24
  25. 25. Thank youAmi Levin, SolidQ

×