ฉันควรทำดัชนีฟิลด์บิตใน SQL Server หรือไม่

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

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

แน่นอนฉันสามารถทดสอบและตรวจสอบแผนการดำเนินการได้และฉันจะทำเช่นนั้น แต่ฉันก็อยากรู้เกี่ยวกับทฤษฎีที่อยู่เบื้องหลัง Cardinality มีความสำคัญเมื่อใดและเมื่อใดไม่?

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

เมื่อคุณขอชุดแถว SQL จะใช้ดัชนีเพื่อค้นหาแถวได้เร็วกว่าการสแกนตาราง (ดูทุกแถว)

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

เมื่อคุณทำดัชนีคอลัมน์จำนวนเต็มดัชนีของ SQL จะมีชุดแถวสำหรับค่าดัชนีแต่ละค่า หากคุณมีช่วง 1 ถึง 10 คุณจะมีดัชนีชี้วัด 10 ตัว ขึ้นอยู่กับจำนวนแถวที่สามารถเพจได้แตกต่างกัน หากคำค้นหาของคุณค้นหาดัชนีที่ตรงกับ "1" แล้วโดยที่ Name มี "Fred" (สมมติว่าคอลัมน์ Name ไม่ได้รับการจัดทำดัชนี) SQL จะได้รับชุดของแถวที่ตรงกับ "1" อย่างรวดเร็วจากนั้นตารางจะสแกนเพื่อค้นหาส่วนที่เหลือ

ดังนั้นสิ่งที่ SQL กำลังทำอยู่คือการพยายามลดชุดการทำงาน (จำนวนแถว) ที่ต้องทำซ้ำ

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

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

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

create index [IX_foobar] on dbo.Foobar (FooID) where yourBitColumn = 1

สิ่งนี้จะสร้างดัชนีที่มีขนาดเล็กลงอย่างมากซึ่งเครื่องมือเพิ่มประสิทธิภาพนั้นฉลาดพอที่จะใช้เมื่อเป็นเพรดิเคตในข้อความค้นหาของคุณ

100 ล้านเรกคอร์ดที่มีเพียงไม่กี่ฟิลด์ที่ตั้งค่าฟิลด์บิตเป็น 1? ใช่ฉันคิดว่าการสร้างดัชนีเขตข้อมูลบิตจะช่วยเร่งการค้นหาระเบียน bit = 1 ได้อย่างแน่นอน คุณควรได้รับเวลาค้นหาลอการิทึมจากดัชนีจากนั้นแตะเพียงไม่กี่หน้าด้วยระเบียน bit = 1 มิฉะนั้นคุณจะต้องแตะทุกหน้าของตารางบันทึก 100 ล้านแผ่น

จากนั้นอีกครั้งฉันไม่ใช่ผู้เชี่ยวชาญด้านฐานข้อมูลและอาจพลาดบางอย่างที่สำคัญไป

หากการแจกแจงของคุณค่อนข้างเป็นที่รู้จักและไม่สมดุลเช่น 99% ของแถวเป็นบิต = 1 และ 1% เป็นบิต = 0 เมื่อคุณทำคำสั่ง WHERE ด้วยบิต = 1 การสแกนแบบเต็มตารางจะอยู่ในเวลาเดียวกันกับ การสแกนดัชนี หากคุณต้องการมีคิวรีแบบรวดเร็วโดยที่ bit = 0 วิธีที่ดีที่สุดที่ฉันรู้คือสร้างดัชนีที่กรองแล้วโดยเพิ่มอนุประโยค WHERE bit = 0 ด้วยวิธีนี้ดัชนีนั้นจะเก็บเฉพาะแถว 1% เท่านั้น จากนั้นการทำ WHERE bit = 0 จะทำให้เครื่องมือเพิ่มประสิทธิภาพการสืบค้นเลือกดัชนีนั้นและแถวทั้งหมดจากนั้นจะเป็นบิต = 0 นอกจากนี้คุณยังได้รับประโยชน์จากการมีพื้นที่ดิสก์จำนวนน้อยมากที่ต้องการเปรียบเทียบดัชนีทั้งหมดบนบิต .

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

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

ในกรณีที่คุณยังไม่ได้อ่าน Jason Massie เขียนบทความเมื่อเร็ว ๆ นี้ซึ่งกล่าวถึงหัวข้อนี้

http://statisticsio.com/Home/tabid/36/articleType/ArticleView/articleId/302/Never-Index-a-BIT.aspx

แก้ไข: ตำแหน่งบทความใหม่ - http://sqlserverpedia.com/blog/sql-server-bloggers/never-index-a-bit

เครื่อง Wayback สำหรับตำแหน่งบทความ "ใหม่" ก่อนหน้านี้: http://web.archive.org/web/20120201122503/http://sqlserverpedia.com/blog/sql-server-bloggers/never-index-a-bit/

ตำแหน่ง SQL Server Pedia ใหม่คือ Toadworld ซึ่งมีบทความใหม่จาก Kenneth Fisher ที่พูดถึงหัวข้อนี้:

http://www.toadworld.com/platforms/sql-server/b/weblog/archive/2014/02/17/dba-myths-an-index-on-a-bit-column-will-never-be- ใช้แล้ว. aspx

ทางกลับเครื่อง: http://web.archive.org/web/20150508115802/http://www.toadworld.com/platforms/sql-server/b/weblog/archive/2014/02/17/dba-myths-an -index-on-a-bit-column-will-never-be-used.aspx

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

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

อย่างที่คนอื่นบอกคุณจะต้องวัดสิ่งนี้ ฉันจำไม่ได้ว่าเคยอ่านสิ่งนี้ที่ไหน แต่คอลัมน์ต้องมีคาร์ดินาลิตี้สูงมาก (ประมาณ 95%) เพื่อให้ดัชนีมีประสิทธิภาพ การทดสอบที่ดีที่สุดของคุณคือการสร้างดัชนีและตรวจสอบแผนการดำเนินการสำหรับค่า 0 และ 1 ของฟิลด์ BIT หากคุณเห็นการดำเนินการค้นหาดัชนีในแผนการดำเนินการคุณจะรู้ว่าดัชนีของคุณจะถูกใช้

แนวทางปฏิบัติที่ดีที่สุดของคุณคือการทดสอบด้วยพื้นฐาน SELECT * FROM table WHERE BitField = 1; ค้นหาและค่อยๆสร้างฟังก์ชันการทำงานจากที่นั่นทีละขั้นตอนจนกว่าคุณจะมีแบบสอบถามที่เป็นจริงสำหรับแอปพลิเคชันของคุณตรวจสอบแผนการดำเนินการทุกขั้นตอนเพื่อให้แน่ใจว่ายังคงใช้การค้นหาดัชนีอยู่ เป็นที่ยอมรับไม่มีการรับประกันว่าแผนการดำเนินการนี้จะถูกนำไปใช้ในการผลิต แต่มีโอกาสที่จะเป็นเช่นนั้น

ข้อมูลบางส่วนสามารถพบได้ในฟอรัม sql-server-performance.comและในบทความที่อ้างอิง

"ฉันจำได้ว่าอ่านถึงจุดหนึ่งว่าการสร้างดัชนีเขตข้อมูลที่มีคาร์ดินาลลิตี้ต่ำ (จำนวนค่าที่แตกต่างกันต่ำ) นั้นไม่คุ้มค่าจริงๆ"

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

หากเป้าหมายของคุณคือการค้นหาระเบียนที่ค่าของเขตข้อมูลบิตเท่ากับ '1' เร็วขึ้นคุณอาจลองใช้มุมมองที่จัดทำดัชนีของตารางฐานของคุณซึ่งมีเฉพาะระเบียนที่เขตข้อมูลบิตของคุณเท่ากับ '1' ในรุ่นองค์กรหากแบบสอบถามสามารถใช้มุมมองที่จัดทำดัชนีแทนตารางที่ระบุเพื่อปรับปรุงประสิทธิภาพการสืบค้นจะใช้มุมมอง ตามทฤษฎีแล้วสิ่งนี้จะเพิ่มความเร็วของการสืบค้นแบบเลือกซึ่งค้นหาเฉพาะระเบียนที่มีค่าฟิลด์บิตเป็น '1'

http://www.microsoft.com/technet/prodtechnol/sql/2005/impprfiv.mspx

ทั้งหมดนี้ถือว่าคุณเป็น Microsoft SQL Server 2005 Enterprise เช่นเดียวกันกับปี 2008 ฉันไม่คุ้นเคยกับเวอร์ชันนั้น

หากคุณต้องการทราบว่าดัชนีมีผลตามที่คุณต้องการหรือไม่: ทดสอบแล้วทดสอบอีกครั้ง

โดยทั่วไปคุณไม่ต้องการดัชนีที่ไม่แคบลงในตารางของคุณมากพอเนื่องจากค่าใช้จ่ายในการรักษาดัชนี (ต้นทุน> กำไร) แต่ถ้าดัชนีในกรณีของคุณลดครึ่งตารางคุณอาจได้รับบางอย่าง แต่วางไว้บนโต๊ะ ทุกอย่างขึ้นอยู่กับขนาด / โครงสร้างที่แน่นอนของตารางของคุณและวิธีการใช้งาน (จำนวนการอ่าน / เขียน)

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

คุณไม่สามารถสร้างดัชนีเขตข้อมูลบิตใน SQL Server 2000 ได้ตามที่ระบุไว้ในหนังสือออนไลน์ในขณะนั้น:

นิดหน่อย

ข้อมูลจำนวนเต็ม 1, 0 หรือ NULL

หมายเหตุ

คอลัมน์ประเภทบิตไม่สามารถมีดัชนีได้

ใช่หากคุณมีแถวเพียงไม่กี่แถวจากหลายล้านดัชนีจะช่วยได้ แต่ถ้าคุณต้องการทำในกรณีนี้คุณต้องสร้างคอลัมน์ a tinyint.

หมายเหตุ : Enterprise Manager จะไม่อนุญาตให้คุณสร้างดัชนีในคอลัมน์บิต หากคุณต้องการคุณยังคงสามารถสร้างดัชนีด้วยตนเองในคอลัมน์บิต:

CREATE INDEX IX_Users_IsActiveUsername ON Users
(
   IsActive,
   Username
)

แต่ SQL Server 2000 จะไม่ใช้ดัชนีดังกล่าวจริง ๆ - เรียกใช้แบบสอบถามที่ดัชนีจะเป็นตัวเลือกที่สมบูรณ์แบบเช่น:

SELECT TOP 1 Username 
FROM Users
WHERE IsActive = 0

SQL Server 2000 จะทำการสแกนตารางแทนโดยทำราวกับว่าดัชนีไม่มีอยู่จริง ถ้าคุณเปลี่ยนคอลัมน์เป็น smallint SQL Server 2000 จะทำการค้นหาดัชนี นอกจากนี้แบบสอบถามที่ไม่ครอบคลุมต่อไปนี้:

SELECT TOP 1 * 
FROM Users
WHERE IsActive = 0

มันจะทำการค้นหาดัชนีตามด้วยการค้นหาบุ๊กมาร์ก

SQL Server 2005 มีการสนับสนุนแบบ จำกัด สำหรับดัชนีบนคอลัมน์บิต ตัวอย่างเช่น:

SELECT TOP 1 Username 
FROM Users
WHERE IsActive = 0

จะทำให้ดัชนีค้นหาผ่านดัชนีครอบคลุม แต่กรณีที่ไม่ครอบคลุม:

SELECT TOP 1 * 
FROM Users
WHERE IsActive = 0

จะไม่ทำให้เกิดการค้นหาดัชนีตามด้วยการค้นหาบุ๊กมาร์กจะทำการสแกนตาราง (หรือสแกนดัชนีคลัสเตอร์) แทนที่จะทำการค้นหาดัชนีตามด้วยการค้นหาบุ๊กมาร์ก

ตรวจสอบโดยการทดลองและการสังเกตโดยตรง

ตอบช้ามาก ...

ใช่มันจะมีประโยชน์ตามทีม SQL CAT (อัปเดตได้รับการรวม)

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

Cardinality เป็นปัจจัยหนึ่งส่วนอีกปัจจัยหนึ่งคือดัชนีแบ่งข้อมูลของคุณได้ดีเพียงใด หากคุณมีประมาณครึ่ง 1s และ 0 ครึ่งก็จะช่วยได้ (สมมติว่าดัชนีนั้นเป็นเส้นทางที่ดีกว่าในการเลือกดัชนีอื่น ๆ ) อย่างไรก็ตามคุณแทรกและอัปเดตบ่อยแค่ไหน? การเพิ่มดัชนีสำหรับประสิทธิภาพการเลือกยังส่งผลกระทบต่อประสิทธิภาพของ INSERT, UPDATE และ DELETE ดังนั้นโปรดจำไว้ว่า

ฉันจะบอกว่าถ้า 1 ถึง 0s (หรือในทางกลับกัน) ไม่ดีกว่า 75% ถึง 25% ไม่ต้องกังวล

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

Ian Boyd ถูกต้องเมื่อเขาบอกว่าคุณไม่สามารถทำได้ผ่าน Enterprise Manager สำหรับ SQL 2000 (ดูบันทึกของเขาเกี่ยวกับการสร้างผ่าน T-SQL

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