ทำไมการวนซ้ำซ้อนกันจึงสนับสนุนเฉพาะการรวมซ้ายเท่านั้น


11

ในบล็อกของ Craig Freedman เข้าร่วม Nested Loops Joinเขาอธิบายว่าทำไมการเข้าร่วม loops แบบซ้อนไม่สามารถรองรับการเข้าร่วมด้านนอกที่ถูกต้อง:

ปัญหาคือเราสแกนตารางด้านในหลาย ๆ ครั้ง - หนึ่งครั้งสำหรับแต่ละแถวของการรวมภายนอก เราอาจพบแถวภายในเดียวกันหลายครั้งในระหว่างการสแกนหลายครั้ง เราสามารถสรุปได้ว่าจุดภายในแถวใดแถวหนึ่งไม่ได้หรือจะไม่เข้าร่วม?

ใครช่วยอธิบายสิ่งนี้ด้วยวิธีที่ง่ายและให้ความรู้ได้จริงหรือ?

หมายความว่าการวนรอบเริ่มต้นด้วยตารางด้านนอก ( R1) และการสแกนด้านใน ( R2) หรือไม่

ฉันเข้าใจว่าสำหรับR1ค่าที่ไม่ได้เข้าร่วมR2ควรแทนที่ด้วยNULLชุดผลลัพธ์จึงกลายเป็น ( NULL, R2) สำหรับฉันดูเหมือนว่าเป็นไปไม่ได้ที่จะคืนR2ค่าเมื่อR1ไม่ได้เข้าร่วมด้วยเหตุผลที่ไม่สามารถรู้ว่าR2จะคืนค่าใด แต่นั่นไม่ใช่วิธีที่อธิบาย หรือมันคืออะไร?

ในความเป็นจริง SQL Server จะปรับให้เหมาะสม (และมักจะแทนที่) RIGHT JOINด้วยLEFT JOINแต่คำถามคือเพื่ออธิบายว่าทำไมมันเป็นไปไม่ได้ทางเทคนิคสำหรับตรรกะNESTED LOOPS JOINการใช้งาน / การสนับสนุนRIGHT JOIN

คำตอบ:


12

ปัญหาหลักที่นี่คือการดำเนินงานของการเข้าร่วม outer ใช้ลูปซ้อนกันในทางเทคนิคซึ่งอยู่ตรงข้ามกับทางตรรกะที่โต๊ะด้านในมีการเข้าถึงผ่านห่วงด้านนอกและโต๊ะด้านนอกมีการเข้าถึงผ่านภายในวง

รับตาราง A และ B มาดำเนินการA LEFT JOIN Bกัน

A
--
1
2

B
_
1
3

ก่อนอื่นมาทำด้วยวิธีที่ " เป็นธรรมชาติ "

เราย้ำผ่าน A.
บันทึกการเข้าถึงเรา 1.
เราย้ำผ่านบี
เราพบระเบียน 1 ในบีและเอาท์พุท1-1

เราเก็บ iterating ผ่าน A.
เราเข้าถึงบันทึก 2.
เราย้ำผ่านบี
เราไม่พบการแข่งขันใด ๆ ในบี
เราเอาท์พุท2 โมฆะ

ทีนี้ลองทำในวิธีที่ " ตรงกันข้าม "

เราย้ำผ่านบี
เราเข้าถึงบันทึก 1.
เราย้ำผ่าน A.
เราพบระเบียน 1 ใน A และเอาท์พุท1-1

เราวนซ้ำผ่าน B.
เราเข้าถึงบันทึก 3
เราวนซ้ำผ่าน A.
เราไม่พบการแข่งขันใน A.

ตอนนี้จำได้ว่ามันเป็นA LEFT JOIN Bซึ่งหมายความว่านอกเหนือไป1-1เราควรเอาท์พุท2 โมฆะ
ปัญหาคือ ณ จุดนั้นเราไม่มีความคิดที่จะบันทึกรหัส A เรามีการแข่งขัน (1) และการบันทึกที่เราไม่ได้ (2)


สิ่งนี้สามารถแก้ไขได้ในรูปแบบต่าง ๆ เช่นโดยถือบิตอาเรย์สำหรับตาราง A
เมื่อพบเรกคอร์ดA เป็นการจับคู่เราจะทำเครื่องหมายในอาเรย์บิต
ในตอนท้ายของลูปซ้อนเราจะผ่านบิตเรย์และเอาท์พุทและเอาท์พุทบันทึกใด ๆ ที่ไม่ได้ทำเครื่องหมาย
เห็นได้ชัดว่าซับซ้อนกว่าลูปซ้อนแบบ "เป็นธรรมชาติ"


13

สิ่งที่ฉันไม่ชอบในบทความที่เชื่อมโยงเป็นคำว่า"วงซ้อนกันเข้าร่วมขั้นตอนวิธีการไม่สนับสนุนตรรกะเข้าร่วมดำเนินการที่เหมาะสมเข้าร่วม"

ในขณะที่มีข้อ จำกัด ถ้อยคำในจุดนี้ค่อนข้างสับสน ฉันหวังว่าสิ่งต่อไปนี้จะอธิบายสิ่งต่าง ๆ ได้ดีขึ้น:

อัลกอริทึมเข้าร่วม lop ซ้อนกันเกี่ยวข้องกับสองตาราง (ไม่ว่าจะเป็นตารางฐานหรือชุดผลลัพธ์ของการดำเนินงานก่อนหน้านี้ไม่เกี่ยวข้อง) ซึ่งมีชื่อตารางด้านนอกและด้านในและพวกเขาจะได้รับการปฏิบัติในวิธีที่แตกต่างกันโดยอัลกอริทึม วนรอบและตาราง "ด้านใน" ที่ห่วงด้านใน)

ดังนั้นสมมติว่าเราได้เข้าร่วม:

A (some_type) JOIN B

อัลกอริทึมสามารถดำเนินการได้ทั้ง:

outer-loop-A  nested-loop  inner-loop-B

หรือ:

outer-loop-B  nested-loop  inner-loop-A

ตอนนี้ถ้า ( some_type) เป็นINNERหรือCROSSเข้าร่วมก็ไม่มีข้อ จำกัด นักวางแผนสามารถเลือกระหว่างสองวิธี (ที่มีคุณสมบัติด้านประสิทธิภาพที่แตกต่างกันขึ้นอยู่กับขนาดของชุดการกระจายค่าของคอลัมน์ที่เข้าร่วมดัชนี ฯลฯ โดยปกติแล้วตารางที่เล็กที่สุดจะถูกเลือกให้เป็นตาราง "ด้านนอก" ในอัลกอริทึม)

แต่เมื่อsome_typeจะLEFTเข้าร่วมก็สามารถใช้:

outer-loop-A  nested-loop  inner-loop-B

และไม่

outer-loop-B  nested-loop  inner-loop-A

และเนื่องจากRIGHTสามารถเขียนใหม่เป็นการLEFTเข้าร่วมได้จึงมีข้อ จำกัด เหมือนกันในทางกลับกัน สำหรับA RIGHT JOIN B(ซึ่งสามารถเขียนใหม่ได้B LEFT JOIN A) มันสามารถใช้ได้เฉพาะ:

outer-loop-B  nested-loop  inner-loop-A

และไม่วิธีอื่น ๆ รอบ ๆ*

ข้อ จำกัด เดียวกันนี้ใช้กับเซมิโคลอนซ้าย, เซกเมนต์ซ้าย, เซกเมนต์ซ้าย, เซกเมนต์ซ้ายและเซกเมนต์ป้องกันขวา

การFULLเข้าร่วมในอีกทางหนึ่งไม่สามารถจัดการได้โดยตรงด้วยอัลกอริทึมการเข้าร่วมลูปซ้อนกัน บทความนี้อธิบายได้ดีมาก (ใกล้ถึงจุดสิ้นสุด) วิธีการรวมแบบเต็มสามารถเขียนใหม่ (และเป็นเครื่องมือเพิ่มประสิทธิภาพ) สำหรับการรวมฝ่ายซ้ายและการต่อต้านเซมิไฟทางซ้ายซึ่งอาจมีการวางแผนเป็นสองวงซ้อนกัน (และ ยูเนี่ยน)

* ดัง ที่ Dudu Markovitz อธิบายในคำตอบของเขาวิธีย้อนกลับจะสามารถใช้ได้ แต่ถ้าเราแก้ไขอัลกอริทึมการเข้าร่วมแบบวนซ้ำแบบซ้อนเพื่อให้มีโครงสร้างพิเศษและขั้นตอนพิเศษในตอนท้าย


ดีที่ชี้แจงจำนวนมาก คำตอบของคุณรวมกับ Dudu M: อธิบายได้ดีมาก!
GordonLiddy
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.