ลำดับฟิลด์ในลำดับดัชนีคอมโพสิตที่มีการเลือกสูงและฟิลด์การเลือกต่ำ

ฉันมีตาราง SQL Server ที่มีมากกว่า 3 พันล้านแถว หนึ่งในคำถามของฉันใช้เวลานานมากดังนั้นฉันจึงพิจารณาที่จะเพิ่มประสิทธิภาพ แบบสอบถามมีลักษณะดังนี้:

SELECT [Enroll_Date]
      ,Count(*) AS [Record #]
      ,Count(Distinct UserID) AS [User #]
  FROM UserTable
  GROUP BY [Enroll_Date]

[Enroll_Date] เป็นคอลัมน์การเลือกต่ำที่มีค่าน้อยกว่า 50 ค่าในขณะที่คอลัมน์ UserID เป็นคอลัมน์เลือกสูงที่มีค่าแตกต่างกันมากกว่า 200 ล้านรายการ จากการวิจัยของฉันฉันเชื่อว่าฉันควรสร้างดัชนีคอมโพสิตแบบไม่รวมกลุ่มในสองคอลัมน์นี้และในทางทฤษฎีแล้วคอลัมน์การเลือกสูงควรเป็นคอลัมน์แรก แต่ฉันไม่แน่ใจว่าในกรณีของฉันจะทำงานได้เพราะฉันใช้คอลัมน์หัวกะทิต่ำในกลุ่มโดยข้อ

ตารางนี้ไม่มีดัชนีคลัสเตอร์

ในฐานะที่เป็นทางเลือกในการแก้ปัญหา @ AaronBertrand ฯ (ถ้าคุณไม่สามารถหรือไม่ต้องการที่จะสร้างมุมมองที่จัดทำดัชนี) (Enroll_Date, UserID)ฉันอยากจะแนะนำให้คุณสร้างดัชนีใน หากคำถามประเภทนี้พบได้บ่อยบนโต๊ะของคุณนี่อาจเป็นดัชนีที่จัดเป็นกลุ่มของคุณ

โดยทั่วไปฉันจะไม่แนะนำดัชนีการเลือกสูงในฐานะ "แนวปฏิบัติที่ดีที่สุด" ทั่วไป แต่ให้พิจารณาว่าดัชนีใดที่จะทำให้ประสิทธิภาพการค้นหาของคุณดีที่สุด

ดัชนีใน(Enroll_Date, UserID)จะให้แผนแบบสอบถามที่ปรับให้เหมาะสมและไม่มีการบล็อกด้วยการรวมสตรีม

"การไม่บล็อก" ในบริบทนี้หมายความว่าแบบสอบถามไม่จำเป็นต้องบัฟเฟอร์ข้อมูลจำนวนมาก (เช่นการเรียงลำดับหรือการรวมแฮช) ซึ่งหมายความว่า (a) เริ่มส่งคืนแถวทันทีและ ( b) ใช้งานได้จริงไม่มีหน่วยความจำในการทำงาน

คำตอบ Aarons เป็นทางออกที่ดี ฉันจะตอบคำถามสมมติว่าคุณไม่ต้องการใช้วิธีการนั้น

แบบสอบถามที่คุณโพสต์จะมักจะดำเนินการโดยการจัดกลุ่มเป็นครั้งแรกในแล้วอีกครั้งใน(Enroll_Date, UserID) (Enroll_Date)การเพิ่มประสิทธิภาพนี้เป็นของใหม่กับ SQL Server 2012 COUNT DISTINCTมันจะมีผลในกรณีที่เป็นหนึ่งเดียว

ดัชนีในคอลัมน์ทั้งสองในลำดับที่เฉพาะเจาะจง(Enroll_Date, UserID)จะพอเพียงเพื่อให้ได้แผนที่มีประสิทธิภาพซึ่งจะทำให้การสแกนดัชนีเป็นช่องทางรวมสองรายการที่ต่อเนื่องกัน ลำดับตรงกันข้ามจะไม่เปิดใช้งานแผนนั้น

(Enroll_Date, UserID)ดังนั้นการใช้คำสั่ง คุณไม่มีทางเลือกที่นี่

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

CREATE VIEW dbo.MyIndexedView
WITH SCHEMABINDING
AS 
  SELECT Enroll_Date, UserID, RawCount = COUNT_BIG(*)
  FROM dbo.UserTable
  GROUP BY Enroll_Date, UserID;
GO

CREATE UNIQUE CLUSTERED INDEX CIX_miv ON dbo.MyIndexedView(Enroll_Date, UserID);

ซึ่งจะใช้เวลาสักครู่ในการสร้างและแน่นอนว่าจะต้องมีการบำรุงรักษาตลอดการดำเนินการ DML ทั้งหมดเช่นเดียวกับดัชนีในตารางฐาน

ตอนนี้คิวรีที่เทียบกับมุมมองนี้จะค่อนข้างคล้ายกัน - แต่ละแถวในมุมมองตอนนี้แสดงคอมโบของผู้ใช้ / วันที่ที่แตกต่างกันดังนั้นตัวเลขสามารถคำนวณได้ด้วย COUNT (*) เดียวในขณะที่จำนวนแถวทั้งหมดในตารางฐานคือ รวมแล้วบางส่วนสำหรับคุณตอนนี้คุณเพียงแค่ต้องเพิ่มพวกเขาโดยใช้ SUM ต่อวัน:

SELECT Enroll_Date, 
  [Record #] = SUM(RawCount),
  [User #] = COUNT(*)
FROM dbo.MyIndexedView WITH (NOEXPAND)
GROUP BY Enroll_Date; 

เพิ่ม NOEXPAND คำใบ้หลังจากจดจำนี้และนี้

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

และถ้าคุณใช้คำสั่ง WHERE ทั่วไปร่วมกันที่เหมือนกันกับ Enroll_Date สำหรับช่วงที่กำหนดไว้ชัดเจน (เช่นไตรมาสปัจจุบันหรือปีปัจจุบัน) คุณสามารถเพิ่มดัชนีที่กรองที่ตรงกันซึ่งลด I / O ให้มากขึ้น (แต่มีเสมอ การออก)

คุณอาจพิจารณาวางดัชนีคลัสเตอร์บนตารางฐาน นี่ไม่ใช่กรณีการใช้งานที่หายากซึ่งได้รับประโยชน์จากฮีป