ใช้มุมมองที่จัดทำดัชนีไว้สำหรับการรวม - ดีเกินจริงหรือ?

เรามีคลังข้อมูลที่มีจำนวนเรกคอร์ดที่ค่อนข้างใหญ่ (10-20 ล้านแถว) และมักเรียกใช้คิวรีที่นับเร็กคอร์ดระหว่างวันที่แน่นอนหรือนับจำนวนเรกคอร์ดด้วยค่าสถานะที่แน่นอนเช่น

SELECT
    f.IsFoo,
    COUNT(*) AS WidgetCount
FROM Widgets AS w
JOIN Flags AS f
    ON f.FlagId = w.FlagId
WHERE w.Date >= @startDate
GROUP BY f.IsFoo

ประสิทธิภาพไม่น่ากลัว แต่อาจค่อนข้างเชื่องช้า (อาจใช้เวลา 10 วินาทีในแคชเย็น)

เมื่อเร็ว ๆ นี้ฉันค้นพบว่าฉันสามารถใช้GROUP BYในมุมมองที่จัดทำดัชนีและลองใช้บางสิ่งที่คล้ายกับต่อไปนี้

CREATE VIEW TestView
WITH SCHEMABINDING
AS
    SELECT
        Date,
        FlagId,
        COUNT_BIG(*) AS WidgetCount
    FROM Widgets
    GROUP BY Date, FlagId;
GO

CREATE UNIQUE CLUSTERED INDEX PK_TestView ON TestView
(
    Date,
    FlagId
);

ด้วยเหตุนี้ประสิทธิภาพของการสืบค้นแรกของฉันอยู่ที่ <100ms และผลลัพธ์ & ดัชนีการดูคือ <100k (แม้ว่าการนับแถวของเราจะมีขนาดใหญ่ช่วงวันที่และ ID การตั้งค่าสถานะหมายความว่ามุมมองนี้มี 1,000-2,000 แถวเท่านั้น)

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

สำหรับฉันดูเหมือนว่ามันจะดีเกินไปที่จะเป็นจริง - ใช่ไหม? ฉันต้องระวังอะไรเมื่อใช้มุมมองที่จัดทำดัชนีด้วยวิธีนี้

ตามที่คุณสังเกตเห็นมุมมองของตัวเองเท่านั้น materializes ขนาดเล็กจำนวนแถว - ดังนั้นแม้ว่าคุณปรับปรุงตารางทั้งที่เพิ่มเติม I / O ที่เกี่ยวข้องกับการปรับปรุงมุมมองเป็นเล็กน้อย คุณอาจรู้สึกถึงความเจ็บปวดที่ใหญ่ที่สุดที่คุณจะรู้สึกเมื่อสร้างมุมมอง สิ่งที่ใกล้เคียงที่สุดถัดไปคือถ้าคุณเพิ่ม gazillion row ในตารางฐานที่มี ID ใหม่จำนวนมากที่ต้องการแถวใหม่ในมุมมอง

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

น่าเสียดายที่หลายคนคิดว่าการจัดทำดัชนีมุมมองนั้นเป็นเรื่องมหัศจรรย์ - ดัชนีจะไม่ทำให้ทุกการดูมีประสิทธิภาพมากขึ้นโดยเฉพาะมุมมองที่เข้าร่วมตารางและ / หรือสร้างจำนวนแถวเท่ากันกับที่มา (หรือทวีคูณ) ในกรณีเหล่านี้ I / O จากมุมมองนั้นเหมือนกันหรือแย่กว่าแบบสอบถามต้นฉบับไม่เพียงเพราะมีแถวที่เหมือนกันหรือหลายแถว แต่บ่อยครั้งที่พวกเขากำลังจัดเก็บและทำให้คอลัมน์เป็นจริงมากขึ้นเช่นกัน ดังนั้นการทำให้เป็นรูปธรรมล่วงหน้านั้นไม่ได้ประโยชน์ใด ๆ ตั้งแต่ - แม้กับ SSD - I / O, เครือข่ายและการประมวลผล / การแสดงผลของลูกค้ายังคงเป็นคอขวดหลักในการส่งคืนชุดผลลัพธ์ขนาดใหญ่ให้กับลูกค้า การออมที่คุณหลีกเลี่ยงการเข้าร่วมที่รันไทม์นั้นไม่สามารถวัดได้เมื่อเปรียบเทียบกับทรัพยากรอื่น ๆ ทั้งหมดที่คุณยังคงใช้อยู่

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

เอ้ยฉันมีความหมายที่จะบล็อกเกี่ยวกับหัวข้อนี้

คำตอบของ Aarons ครอบคลุมคำถามนี้ดี สองสิ่งที่จะเพิ่ม:

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

ฉันใช้ทั้งการรวมตัวและเข้าร่วมมุมมองด้วยผลประโยชน์สูงสุด

ทั้งหมดในทุกกรณีการใช้งานของคุณดูเหมือนว่าเป็นกรณีที่สมบูรณ์แบบ มุมมองการจัดทำดัชนีเป็นเทคนิคที่ underutilized ไกล