การเพิ่มดัชนีในคอลัมน์บิตช้าลงอย่างมีนัยสำคัญหรือไม่?


11

ฉันมีตารางที่มีประมาณ 1 ล้านถึง 5 ล้านบันทึก ส่วนเล็ก ๆ ของระเบียนนั้นมีหนึ่งในคอลัมน์บิตตั้งค่าเป็น 'TRUE' จำเป็นต้องค้นหาระเบียนนั้นอย่างรวดเร็ว ฉันคิดว่าดัชนีสามารถเพิ่มความเร็วในการค้นหาในคอลัมน์นี้ แต่ฉันกลัว INSERT ดังนั้นคำถามของฉัน

ฐานข้อมูลทำงานเหมือนคลังข้อมูลดังนั้นจึงมี SELECT จำนวนมากและขนาดเล็ก (สูงสุด 10-20 ต่อวัน) แต่มี INSERT ที่ค่อนข้างใหญ่ (มากถึง 200,000 ระเบียนในคราวเดียว) ฉันกลัวว่าจะนำเข้าฐานข้อมูลนานขึ้น


5
SQL Server รุ่นใด ถ้าปี 2008+ ดูเหมือนว่าดัชนีที่ถูกกรองอาจเป็นสิ่งที่คุณต้องการ
Martin Smith

SQL Server 2005
marioosh

1
คุณสามารถแยกตาราง (เพิ่มตารางใหม่ที่มีเพียงหนึ่งคอลัมน์คือ PK ของตารางซึ่งจะมีประชากรเพียงแถวเหล่านั้นที่คอลัมน์บิตเป็นจริง - ในท้ายที่สุดคุณสามารถลบคอลัมน์บิตได้) การจัดทำดัชนี มุมมองจะใช้งานได้เช่นกันในปี 2548 โดยไม่มีดัชนีบางส่วน
ypercubeᵀᴹ

ระวังอย่างเต็มที่กับการจัดทำดัชนีมุมมองตามที่คุณกล่าวถึงคุณมีตัวแทรกขนาดใหญ่ 10-20 ต่อวันการบำรุงรักษามุมมองที่จัดทำดัชนีอาจเกินประโยชน์ของการเพิ่มประสิทธิภาพ ฉันไม่คิดว่า "คุณสมบัตินอกกรอบ" ของ SQL 2005 คุณสามารถใช้เพื่อปรับปรุงสถานการณ์ของคุณ แต่ถ้าคุณทำรายการโครงสร้างตารางปัจจุบันและดัชนีที่มีอยู่เราอาจพบการออกแบบทางเลือกบางอย่าง
Anup Shah

คำตอบ:


8

ดัชนีใน 1 ล้านเร็กคอร์ดนั้นไร้ประโยชน์ เครื่องมือเพิ่มประสิทธิภาพจะไม่ใช้งานเลยคุณเพียงจ่ายค่าบำรุงรักษา ทางเลือกที่ดีกว่าคือการเพิ่มบิตนี้เป็นคีย์ซ้ายสุดในดัชนีคลัสเตอร์

แต่ฉันจะทำให้ตาบอดในที่มืดและเดาว่าสิ่งที่คุณมีคือรูปแบบคิว: บันทึกจะถูกดร็อปในตารางโดยตั้งค่าบิตเป็น 'TRUE' (เช่น 'needsprocessing = true') จากนั้นกระบวนการพื้นหลังจะดู สำหรับเรกคอร์ดเหล่านี้ทำการประมวลผลบางอย่างและอัปเดตบิตเป็น FALSE นี่คือรูปแบบที่อยู่ทั่วไปทุกหนทุกแห่งและยังรู้ด้วยความรักในฐานะ ฉันจะแนะนำวางระเบียนในตารางและวางการแจ้งเตือน (อาจจะเป็นง่ายๆเป็นระเบียน ID แทรกใหม่) ในเวลาเดียวกันเป็นคิว ดูการใช้ตารางเป็นคิว


1
ฉันไม่เห็นจุดดีใด ๆ ในการวางคอลัมน์บิตที่ด้านซ้ายสุดเนื่องจากเราไม่ทราบว่ามีคอลัมน์ตัวกรองอื่น ๆ ที่มีผู้ใช้ระดับสูงอาจมี จนถึงตอนนี้ฉันเคยเห็นคอลัมน์ BIT เป็นตัวเลือกสุดท้ายในดัชนีคลัสเตอร์ แต่ใช่ +1 สำหรับการอ้างอิงที่ดีของ "การใช้ตารางเป็นคิว"
Anup Shah

2
ที่จริงฉันรันการทดสอบและใช่มันจะใช้ดัชนี สร้างตาราง (รหัสประจำตัวบิต myBit) เพิ่ม 100 แถวโดยที่บิตคือ 0 และ 2000000 โดยที่บิตเป็น 1 ตรวจสอบให้แน่ใจว่ามีการอัปเดตสถิติ (ถ้าจำเป็น) และเรียกใช้แบบสอบถามบน myBit = 0 และดัชนีจะถูกใช้
Kenneth Fisher

@ KennethFisher ยกเว้นว่าในรูปแบบความเร็วสูงทั่วไปของการแทรก TRUE / การปรับปรุงเป็น FALSE ทันทีสถิติจะล้าสมัยเสมอ หากคุณต้องการเล่นรูเล็ตรัสเซียด้วยเครื่องมือเพิ่มประสิทธิภาพแทนที่จะออกแบบอย่างชัดเจนคุณจะได้รับสิ่งที่คุณสมควรได้รับ ...
Remus Rusanu

"จะไม่ใช้มันเลย" คำแถลงนั้นถือเป็น 99% ของคดี แต่เราไม่ทราบว่า OP นั้นใช้งานอะไรฉันทำดัชนีสำเร็จแล้ว กรณีใช้งานอยู่
usr

คำถาม - เป็นคำตอบที่นี่ผิดโดยเฉพาะ> "เมื่อคุณจัดทำดัชนีฟิลด์บิต (หรือช่วงแคบ ๆ ) คุณจะลดจำนวนชุดการทำงานตามจำนวนแถวที่ตรงกับค่านั้นเท่านั้นหากคุณมีจำนวนแถวน้อยที่ตรงกับมัน จะช่วยลดชุดการทำงานของคุณลงได้เป็นจำนวนมากสำหรับแถวจำนวนมากที่มีการกระจาย 50/50 อาจทำให้คุณได้รับประสิทธิภาพน้อยมากเมื่อเทียบกับการปรับปรุงดัชนีให้ทันสมัยอยู่เสมอ " ในกรณีใดดัชนีในบิตที่ตรงกับ 1% ของเร็กคอร์ดจะลบล้างความต้องการในการสแกน 99% ของ 1 ล้านสำหรับการเพิ่มที่สำคัญ?
drzaus

2

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

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

สิ่งต่อไปที่ต้องดูคือ "ฉันมีดัชนีจำนวนมากแล้วหรือยัง?" ไม่มีกฎที่ยากและรวดเร็วว่า "มาก" คืออะไร แต่ฉันมักจะไปโดยกฎ 10 ดัชนีเป็นข้อ จำกัด เว้นแต่ฉันต้องการจริงๆใหม่

ความคิดล่าสุดลองทดสอบกับตัวอย่างทดสอบ ตั้งค่าตารางด้วยสองสามล้านแถวเรียกใช้โหลดของคุณเพิ่มดัชนีของคุณแล้วเรียกใช้โหลดของคุณอีกครั้งและดูว่าคุณสังเกตเห็นการเพิ่มขึ้นอย่างมีนัยสำคัญในเวลาโหลด

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

แก้ไข:

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

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