เหตุใดมุมมองที่จัดทำดัชนีจึงไม่อนุญาตดัชนีที่ไม่ซ้ำกันแบบคลัสเตอร์

ฉันได้พิจารณาใช้การจัดทำดัชนีการดูเพื่อเพิ่มประสิทธิภาพในการดูที่ใช้บ่อยที่สุดของเรา

อย่างไรก็ตามมุมมองที่จัดทำดัชนีไม่สนับสนุนดัชนีคลัสเตอร์ที่ไม่ซ้ำกันซึ่งไปเล็กน้อยกับความสำคัญที่กำหนดโดยส่วนที่เหลือของโครงสร้างฐานข้อมูล

ตัวอย่างเช่นที่นี่เป็นเวอร์ชันที่เรียบง่ายของตารางของเราสองสามตัว

-Groups-
Group ID    GroupName

-Users-
UserKey    UserName    FullName     GroupID

ดัชนีอยู่ใน Groups.GroupID (ไม่ทำคลัสเตอร์) และ Users.GroupID (ทำคลัสเตอร์) คีย์คลัสเตอร์ที่อยู่ใน GroupID ในตารางผู้ใช้เป็นช่วงที่ผู้ใช้จากกลุ่มที่เฉพาะเจาะจงมากที่สุดจะถูกดึง เห็นได้ชัดว่าคุณจะมีผู้ใช้หลายคนต่อกลุ่มดังนั้นดัชนีคลัสเตอร์นี้จะไม่ซ้ำกัน

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

ConsumableID    ConsumableVariantID AllowThresholdOverwrite FullPath    GroupID ManufacturerID  Type    ModelID
101              29                 1                       0.1.2.4.    4       3               3       2

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

เหตุใด Views จึงไม่อนุญาตให้มีดัชนีที่ไม่ซ้ำกันในกลุ่มเมื่อตารางปกติทำ

คำอธิบายต่อไปนี้ให้ไว้ในบทความทางเทคนิคของ Microsoft :

ทำไมดัชนีแรกในมุมมองจึงต้องมีข้อมูลที่ไม่ซ้ำกันและไม่ซ้ำกัน

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

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

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

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

ใน SQL Server คีย์ดัชนีทั้งหมดต้องไม่ซ้ำกันภายใน สิ่งนี้จำเป็นต้องใช้เพื่อรับกุญแจล็อคที่อยู่หนึ่งแถวอย่างแน่นอน มันเป็นสิ่งจำเป็นสำหรับการบำรุงรักษาดัชนี ลองนึกภาพ NCI ในคอลัมน์ที่มีค่าเดียวเท่านั้น (ทำซ้ำ 100%) หากแถวถูกลบออกจากตารางเอ็นจิ้นการจัดเก็บจะต้องค้นหาแถว NCI ที่เกี่ยวข้องและลบมันเช่นกัน หากแถว NCI ทั้งหมดแยกไม่ออกก็จะเป็นไปไม่ได้

ดังนั้นคุณจะเห็นว่า CI ในมุมมองต้องไม่ซ้ำกัน (ภายใน) สำหรับเครื่องยนต์ในการทำงาน

หากคุณไม่สร้างดัชนีที่ไม่ซ้ำกันของ SQL Server ยังคงทำให้เป็นเอกลักษณ์ภายใน ในกรณีของ NCI บนตารางฮีปมันจะต่อท้ายบุ๊กมาร์กแถว ในกรณีของ CI ที่ไม่ซ้ำกันมันจะเพิ่มคอลัมน์ตัวแยก ในกรณีของ NCI บนโต๊ะที่มี CI มันจะต่อท้ายคอลัมน์คีย์ CI ใด ๆ ที่คุณยังไม่ได้ระบุ (ซึ่งอาจรวมถึงตัว uniquifier)

ไม่มีคอลัมน์ที่ชัดเจนที่สามารถต่อท้ายในกรณีที่มีการดูดัชนี ดังนั้น SQL Server จะไม่สามารถทำสิ่งนี้ได้โดยอัตโนมัติ

โดยปกติจะค่อนข้างชัดเจนสำหรับคนที่คอลัมน์ที่คุณสามารถเพิ่มเพื่อให้มุมมองมีชุดของคอลัมน์ที่ไม่ซ้ำกันเพื่อใช้ใน CI โดยปกติจะเป็นคอลัมน์ PK หรือ CI ของหนึ่งในตารางพื้นฐาน ถ้ามุมมองมีGROUP BYดัชนีคุณตามปกติในคีย์การจัดกลุ่ม