พื้นฐานการดำเนินการตามแผน - ความสับสนของการจับคู่แฮช


39

ฉันเริ่มเรียนรู้แผนการดำเนินการและสับสนเกี่ยวกับวิธีการทำงานของแฮชที่ตรงกันและทำไมจึงต้องใช้ในการเข้าร่วมง่ายๆ

select Posts.Title, Users.DisplayName
From Posts JOIN Users on
Posts.OwnerUserId = Users.Id
OPTION (MAXDOP 1)

ป้อนคำอธิบายรูปภาพที่นี่

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

สิ่งที่จะทำให้ฉันรู้สึกว่าเป็นเขตข้อมูลทั่วไประหว่างพวกเขารหัสถูกแฮช - แต่ถ้าเป็นกรณีนี้ทำไมจำนวนแฮช?

คำตอบ:


29

ในฐานะที่เป็นคำตอบของ SQLRockstar

ดีที่สุดสำหรับอินพุตขนาดใหญ่และไม่เรียงลำดับ

ตอนนี้

  • จากการสแกนดัชนี Users.DisplayName (สันนิษฐานว่าไม่ใช่แบบคลัสเตอร์) คุณจะได้รับ Users.Id (สมมติว่าเป็นคลัสเตอร์) = ไม่ได้เรียงลำดับ
  • คุณกำลังสแกนกระทู้สำหรับ OwnerUserId = ไม่ได้เรียงลำดับ

นี่คือ 2 อินพุตที่ไม่ได้เรียงลำดับ

ฉันจะพิจารณาดัชนีในตารางโพสต์ใน OwnerUserId รวมถึงชื่อ นี้จะเพิ่มคำสั่งในด้านหนึ่งของการป้อนข้อมูลเพื่อเข้าร่วม + มันจะครอบคลุมดัชนี

CREATE INDEX IX_OwnerUserId ON Posts (OwnerUserId) INCLUDE (Title)

จากนั้นคุณอาจพบว่าดัชนี Users.DisplayName จะไม่ถูกใช้และมันจะสแกน PK แทน


1
อ่าโอเคฉันเห็นแล้วตอนนี้ฉันกำลังคิดถึงผู้ใช้ชื่อผู้ใช้กำลังถูกสั่งโดย PK ซึ่งไม่ใช่กรณีนี้ ตอนนี้การใช้แฮชทำให้ฉันมีความรู้สึกมากขึ้น ขอบคุณ!
Kyle Brandt

1
คุณสามารถลองOPTION (FAST n)คำใบ้โดยที่ n คือจำนวนแถวคร่าวๆที่คุณคาดหวัง สิ่งนี้จะทำอะไรได้คือตั้งค่าเครื่องมือเพิ่มประสิทธิภาพต่อลูปซ้อนกันมากกว่าแฮชรวมเมื่อ n ต่ำ เหตุผลคือการรวมแฮชนั้นรวดเร็วสำหรับการรวมขนาดใหญ่ แต่มีค่าใช้จ่ายในการเริ่มต้นที่สูง ลูปซ้อนกันมีราคาแพงต่อแถว แต่สามารถเริ่มต้นได้อย่างถูกมาก ดังนั้นจึงเป็นเรื่องของการปรับจูนตามข้อมูลจริงและรูปแบบการเข้าถึงของคุณ
ออกุสตุส

1
@Gaius: โดยส่วนตัวแล้วฉันอยากมีดัชนีมากกว่าคำแนะนำ คำใบ้นั้นดีสำหรับข้อความค้นหาเมื่อคุณเพิ่มเท่านั้น Aka คำใบ้กลายเป็นความรับผิดชอบเมื่อเวลาผ่านไป ดัชนีมีแนวโน้มที่จะมีประโยชน์มากขึ้นอีกต่อไป
GBN

1
มันไม่ใช่ทั้งข้อเสนอหรือ:
ออกุสตุส

14

จากhttp://sqlinthewild.co.za/index.php/2007/12/30/execution-plan-operations-joins/

"การเข้าร่วมแฮชเป็นหนึ่งในการดำเนินการเข้าร่วมที่มีราคาแพงกว่าเนื่องจากต้องมีการสร้างตารางแฮชเพื่อทำการเข้าร่วมซึ่งกล่าวว่าเป็นการเข้าร่วมที่ดีที่สุดสำหรับอินพุทขนาดใหญ่และไม่เรียงลำดับ ของการรวม

การเข้าร่วมแฮชก่อนจะอ่านหนึ่งในอินพุตและแฮชคอลัมน์การเข้าร่วมและวางค่าแฮชที่เกิดขึ้นและค่าคอลัมน์ลงในตารางแฮชที่สร้างขึ้นในหน่วยความจำ จากนั้นมันจะอ่านแถวทั้งหมดในอินพุตที่สองแฮชเหล่านั้นและตรวจสอบแถวในที่ฝากข้อมูลแฮชผลลัพธ์สำหรับแถวที่เข้าร่วม "

ลิงก์ไปยังโพสต์นี้:

http://blogs.msdn.com/b/craigfr/archive/2006/08/10/687630.aspx

HTH


ดังนั้นถ้ามันเป็นเพียงช่อง id ฉันเดาว่าฉันไม่เข้าใจความได้เปรียบของการแฮชฟิลด์ id?
Kyle Brandt

+1 สำหรับลิงก์ไปยังบล็อกของ Craig Freedman มีบทความอื่น ๆ อีกมากมายให้เข้าร่วม: blogs.msdn.com/b/craigfr/archive/tags/joins
Jeff

9

ข้อได้เปรียบของการแฮชฟิลด์ที่เป็นตัวเลขคือการที่คุณใช้ค่าที่มากขึ้นและแบ่งมันออกเป็นชิ้นเล็ก ๆ เพื่อให้สามารถใส่ลงในตารางแฮชได้

นี่คือวิธีที่ Grant Fritchey อธิบาย:

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

คุณยังสามารถรับ ebook ฟรีของเขา "ผ่าแผนปฏิบัติการเซิร์ฟเวอร์ SQL" จากลิงก์จากบทความต่อไปนี้:

ที่มา: http://www.simple-talk.com/sql/performance/graphical-execution-plans-for-simple-sql-queries/


บทความชุดอื่นที่น่าสนใจเกี่ยวกับ JOINS: sql-server-performance.com/articles/dba/…
Jeff

ฉันทำงานด้วยวิธีของฉันแม้ว่าจะตัดแผนการดำเนินการของเซิร์ฟเวอร์ SQL - มันยอดเยี่ยมมาก! แต่ฉันติดอยู่กับจุดนี้เล็กน้อย :-P
Kyle Brandt

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