ผลกระทบของการใช้ดัชนีที่ไม่ซ้ำกันที่ไม่ซ้ำกันพร้อมคอลัมน์ครอบคลุมแทนคีย์หลัก


12

เรามีตารางขนาดใหญ่[MyTable]ซึ่งปัจจุบันมีทั้งPrimary Key, และUnique Non Clustered Indexในคอลัมน์เดียวกัน ( [KeyColumn]) ดัชนี U NC ยังมีคอลัมน์ครอบคลุมเพิ่มเติม

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

โปรดทราบว่าตารางจะทำคลัสเตอร์โดยคอลัมน์อื่นทั้งหมด

ie ดังนั้นเรามี:

ALTER TABLE [MyTable]
    ADD CONSTRAINT [PK_MyTable] 
    PRIMARY KEY NONCLUSTERED ([KeyColumn])
GO

และ

CREATE UNIQUE NONCLUSTERED INDEX [IX_MyTable_SomeIndex] 
    ON [MyTable] ([KeyColumn]) 
    INCLUDE ([Column1], [Column2])
GO

เท่าที่ฉันรู้มันเป็นไปไม่ได้ที่จะเพิ่มคอลัมน์ครอบคลุมลงในคีย์หลักดังนั้นฉันตั้งใจจะทำ:

  • ปล่อยข้อ จำกัด ของ Foreign Key ให้ไว้ MyTable.KeyColumn
  • วางคีย์หลักบนMyTable.KeyColumnทั้งหมด
  • เพิ่มคีย์ต่างประเทศลงในตาราง (เช่น RI จะถูกบังคับใช้ผ่านMyTable.KeyColumn)

ความหมายเดียวที่ฉันสามารถทำได้คือเราจะไม่ได้รับสัญลักษณ์ภาพสัญลักษณ์ในแผนภาพ ERD ของเราและความหนาแน่นของดัชนี (ใบไม้) จะน้อยลงเนื่องจากคอลัมน์ที่รวมอยู่

ฉันได้อ่าน/programming/487314/primary-key-or-unique-indexและมีความสุขกับความสมบูรณ์และประสิทธิภาพของการทำสิ่งนี้

คำถามของฉันคือ: วิธีการนี้มีข้อบกพร่องหรือไม่?

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

เพื่อให้พื้นหลังนี้ฉันไม่เคยมีตารางที่ถูกอ้างอิงโดยไม่ต้อง PK อย่างไรก็ตามความจริงที่ว่ามีการเพิ่มดัชนี NC พร้อมคอลัมน์ครอบคลุมลงในตารางหมายความว่าฉันต้องปรับความคิดของฉัน


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

@ jn29098 - อัปเดต ยืนยันว่าเรามีดัชนีแบบกลุ่มในคอลัมน์ที่ไม่ใช่ PK หรือคอลัมน์ครอบคลุมดังนั้นสิ่งนี้ดูเหมือนจะไม่เกี่ยวข้องกับการตัดสินใจนี้
StuartLC

1
คุณแน่ใจหรือไม่ว่าไม่มีเครื่องมือสร้างแบบจำลอง ORM / การสร้างข้อมูลที่จะไม่เกิดปัญหาเมื่อเห็นว่า PK หายไปหรือไม่
Remus Rusanu

ข้อเสียเพียงอย่างเดียวที่ฉันเห็นคือเมื่อหมด PK แล้วคุณมีเพียงหนึ่งดัชนีในคอลัมน์หลักและแบบสอบถามที่ใช้ดัชนี PK พูดสำหรับการสแกนดัชนีในคอลัมน์หรือสั่งซื้อโดยคอลัมน์หลักและไม่ครอบคลุมโดยดัชนี Uniuqe อาจนาฬิกาค่อนข้างพิเศษ IO เนื่องจากหน้าดัชนีของดัชนีที่ไม่เหมือนใครนั้นมีค่ามากกว่าหน้า PK แต่ถ้าอย่างนั้นคนพิถีพิถันจะบอกว่าคุณควรมี PK :)
Gulli Meel

1
ฉันขอแนะนำให้คุณตรวจสอบความมีประโยชน์ของดัชนีนั้นโดยใช้สถิติการใช้ดัชนี DMV และดูว่าแบบสอบถามของคุณถูกใช้งานหรือไม่ตรวจสอบกับดัชนีคีย์ที่ไม่ซ้ำกันและจากนั้น deicde จะเกิดอะไรขึ้นกับแบบสอบถามที่ใช้ ดัชนี ..
Gulli Meel

คำตอบ:


3

การเพิ่มประสิทธิภาพ โดยการลบ PK หรือดัชนีจะมีหน้าน้อยลงสำหรับดัชนีของฉัน = การเขียนที่เร็วขึ้นรวมถึงผลประโยชน์การบำรุงรักษา / การดำเนินงานเช่นดัชนีที่น้อยลงเพื่อจัดเรียงข้อมูล ฯลฯ

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

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

  • เวลาเท่าไหร่ที่จะถูกบันทึกไว้ในหน้าต่างการบำรุงรักษา? ในหน้าต่างสำรอง?

  • พื้นที่เก็บข้อมูลนี้จะบันทึกได้เท่าใด (ไฟล์ข้อมูลไฟล์บันทึกสำรองข้อมูล ฯลฯ )

  • คือINSERTประสิทธิภาพการทำงานบนตารางนี้จริงๆเป็นคอขวดในตอนนี้? มันจะปรับปรุงได้เท่าไหร่? การลบดัชนีเป็นกลยุทธ์ที่ดีที่สุดในการแก้ไขปัญหาหรือไม่

  • สิ่งนี้จะทำให้เกิดปัญหากับเครื่องมือฐานข้อมูลและกรอบงาน (โดยเฉพาะอย่างยิ่ง ORM) ที่คาดว่าแต่ละตารางจะมีคีย์หลักไม่ใช่เฉพาะดัชนีหรือไม่? การจำลองแบบของทรานแซคชันต้องใช้คีย์หลักในตารางที่เผยแพร่

  • สกีมาฐานข้อมูลการจัดทำเอกสารด้วยตนเองมีความสำคัญหรือไม่?

  • แม้จะมีการใช้งาน จำกัด แต่ความแคบของดัชนีคีย์หลักยังช่วยให้เครื่องมือเพิ่มประสิทธิภาพในการสร้างแผนที่มีประสิทธิภาพมากขึ้นสำหรับการค้นหาบางอย่างหรือไม่? (ใช้sys.dm_db_index_usage_statsเพื่อค้นหา)

โดยส่วนตัวจากสิ่งที่คุณบอกเราฉันจะปล่อยให้มันอยู่คนเดียวจนกว่ามันจะสามารถพิสูจน์ได้ว่าทั้งสอง (ก) ดัชนีพิเศษเป็นปัญหาและ (b) การลบมันเป็นทางออก


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

2

แบบสอบถามชนิดเดียวในตารางที่จะทำงานแย่ลง (และแย่ลงเล็กน้อยเท่านั้น) คือแบบสอบถามที่ขอช่วงของค่า KeyColumn เนื่องจากแบบสอบถามในขณะนี้จะให้บริการที่ดีที่สุดโดยดัชนีค้นหาทั่ว PK ของคุณ

มันจะคุ้มค่าในใจว่าค่าใช้จ่ายของการตรวจสอบความสมบูรณ์ของการอ้างอิงสำหรับตารางที่อ้างอิงตารางนี้จะสูงกว่า (อีกครั้งเท่านั้นสูงขึ้นเล็กน้อย)

ตราบใดที่คุณดูแลด้านที่เป็นโมฆะคุณควรจะปรับได้ด้วยดัชนีเดียว

ถ้าเป็นฐานข้อมูลของฉันฉันอาจจะไปหาดัชนีที่ไม่ซ้ำใครสิ่งอื่น ๆ ที่เท่าเทียมกัน


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

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

-2

เท่าที่ฉันรู้มันเป็นไปไม่ได้ที่จะเพิ่มคอลัมน์ครอบคลุมลงในคีย์หลัก

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

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


2
จากย่อหน้าแรก:The table is clustered by another column entirely.
JNK

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