การพิจารณาประสิทธิภาพระหว่างการใช้ PK แบบกว้างเทียบกับคีย์สังเคราะห์แบบแยกต่างหากกับ UQ คืออะไร

ฉันมีตารางหลายตารางที่สามารถระบุระเบียนได้โดยไม่ซ้ำกับสาขาธุรกิจที่หลากหลาย ก่อนหน้านี้ฉันใช้ฟิลด์เหล่านี้เป็น PK โดยคำนึงถึงประโยชน์เหล่านี้:

• เรียบง่าย; ไม่มีฟิลด์ที่ไม่เกี่ยวข้องและมีเพียงหนึ่งดัชนี
• การทำคลัสเตอร์ช่วยให้สามารถผสานการรวมอย่างรวดเร็วและตัวกรองตามช่วง

อย่างไรก็ตามฉันได้ยินกรณีที่ทำเพื่อสร้างIDENTITY INTPK สังเคราะห์และบังคับใช้รหัสธุรกิจด้วยUNIQUEข้อ จำกัดแยกต่างหาก ข้อดีคือการที่ PK แคบทำให้ดัชนีรองมีขนาดเล็กกว่ามาก

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

อนึ่งฉันไม่ได้โต้เถียงกับการใช้คีย์สังเคราะห์ในคลังข้อมูลฉันแค่สนใจว่าจะใช้ PK แบบกว้าง ๆ เพียงครั้งเดียวและเมื่อใดที่จะใช้ PK แบบแคบและอังกฤษแบบกว้าง

ไม่มีข้อเสียอย่างมีนัยสำคัญโดยใช้คีย์ธรรมชาติเป็นดัชนีคลัสเตอร์

• ไม่มีดัชนีที่ไม่ทำคลัสเตอร์
• ไม่มีคีย์ต่างประเทศอ้างอิงตารางนี้ (เป็นแถวหลัก)

ข้อเสียจะเพิ่มการแยกหน้าเนื่องจากการแทรกข้อมูลจะกระจายไปทั่วข้อมูลแทนที่จะเป็นตอนท้าย

ตำแหน่งที่คุณมีดัชนี FKs หรือ NC การใช้ดัชนีแบบคลัสเตอร์ที่แคบตัวเลขและเพิ่มจะมีข้อดี คุณทำซ้ำข้อมูลสองสามไบต์ต่อรายการ NC หรือ FK เท่านั้นไม่ใช่ปุ่ม while business / natural

สำหรับเหตุผลที่อ่านบทความ 5 เกินไปจาก Google

หมายเหตุฉันหลีกเลี่ยงการใช้ "คีย์หลัก"

คุณสามารถมีดัชนีคลัสเตอร์บนคีย์ตัวแทน แต่เก็บ PK ไว้ในกฎเกณฑ์ทางธุรกิจ แต่ไม่ใช่คลัสเตอร์ เพียงตรวจสอบให้แน่ใจว่าคลัสเตอร์นั้นไม่เหมือนใครเพราะ SQL จะเพิ่ม "uniquifier" เพื่อให้มันเป็นเช่นนั้น

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

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

dbms จะใช้ดัชนีชนิดนั้นเพื่อรองรับคีย์ต่างประเทศหากคุณกำหนดด้วยวิธีนั้น

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

การทดสอบแสดงให้เห็นว่าการรวมหมายเลขประจำตัวจะไม่ทำงานเร็วกว่าการอ่านคีย์ธรรมชาติในฐานข้อมูลของเราจนกว่าตารางบางตารางจะมีจำนวนหลายล้านแถว ความกว้างของแถวเกี่ยวข้องกับสิ่งนั้นมาก - แถวที่กว้างขึ้นหมายถึงจำนวนแถวที่พอดีกับหน้าน้อยลงดังนั้นคุณต้องอ่านหน้าเพิ่มเติมเพื่อให้ได้แถว 'n' เกือบทุกโต๊ะของเราอยู่ใน 5NF; ตารางส่วนใหญ่ค่อนข้างแคบ

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

ฉันมีฐานข้อมูล oltp ทั้งหมดที่ออกแบบโดยใช้คอลัมน์ข้อมูลประจำตัวสำหรับการทำคลัสเตอร์ + pk มันทำงานค่อนข้างเร็วในการแทรก / ค้นหา แต่ฉันได้เห็นปัญหาสองสามข้อ:
1. ตัวเลือกการเติมดัชนีไม่มีประโยชน์เพราะส่วนแทรกเกิดขึ้นเฉพาะตอนท้ายของดัชนี
2. พื้นที่เก็บข้อมูลเพิ่มขึ้น ฉันมีตารางที่มีหลายสิบล้านเรคคอร์ดและ 1 int ใช้พื้นที่ด้วยตัวเอง แต่ละตารางที่มีคอลัมน์ข้อมูลเฉพาะสำหรับ pk จะต้องมีดัชนีอื่นสำหรับการค้นหาทางธุรกิจดังนั้นจึงจำเป็นต้องมีพื้นที่จัดเก็บเพิ่มเติม
3. ความยืดหยุ่น นี่เป็นปัญหาที่เลวร้ายที่สุด เนื่องจากการแทรกทุกครั้งจะไปที่จุดสิ้นสุดของดัชนีการแทรกแต่ละครั้งจะเน้นเฉพาะจุดสิ้นสุดของดัชนี (การจัดสรร io สำหรับการเขียน ฯลฯ ) โดยใช้คีย์ธุรกิจเป็นคีย์การทำคลัสเตอร์คุณสามารถกระจายแทรกอย่างสม่ำเสมอในดัชนี นั่นหมายความว่าคุณเพิ่งกำจัดฮอตสปอตขนาดใหญ่ คุณสามารถใช้ไฟล์เพิ่มเติมสำหรับดัชนีแต่ละไฟล์ในไดรฟ์แยกกันได้อย่างง่ายดายแต่ละไดรฟ์ทำงานแยกกัน

ฉันเริ่มเปลี่ยนตารางจากคอลัมน์ข้อมูลประจำตัวเป็นคีย์ธรรมชาติ (อาจแยกจากกันสำหรับการจัดกลุ่ม & pk) ตอนนี้รู้สึกดีขึ้นแล้ว

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

หากคีย์คลัสเตอร์ไม่ง่ายและมีตัวอักษร (char [], varchar, nvarchar) ฉันคิดว่าคำตอบคือ 'มันขึ้นอยู่กับ' คุณควรวิเคราะห์ทีละกรณี

ฉันรักษาหลักการต่อไปนี้: ปรับให้เหมาะสมสำหรับเคียวรีที่พบบ่อยที่สุดขณะที่ลดสถานการณ์เคสที่แย่ที่สุด

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

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

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