การทำดัชนีพื้นที่ใหญ่กว่าพื้นที่ข้อมูลนั้นเป็นสิ่งที่ไม่ดีหรือไม่?

บ่อยครั้งที่ฉันต้องการเรียกใช้แบบสอบถามกับตารางขนาดใหญ่ที่ไม่มีดัชนีที่ถูกต้อง ดังนั้นฉันขอให้ DBA สร้างดัชนีดังกล่าว สิ่งแรกที่เขาทำคือดูที่ตารางสถิติและดูขนาดพื้นที่ดัชนี

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

ฉันไม่รู้สึกว่าปรัชญาของเขาถูกต้อง แต่ฉันไม่สามารถท้าทายเขาได้เพราะเขาเป็นผู้นำ DBA และฉันเป็นนักพัฒนา ฉันรู้สึกว่าแบบสอบถามต้องการดัชนีควรสร้างดัชนีแทนการค้นหา "วิธีแก้ไข" ที่เพิ่งสร้าง SP ที่ไม่สามารถอ่านได้และไม่สามารถแก้ไขได้

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

DBA แสดงสถิติดัชนีให้ฉัน มีประมาณ 10 ดัชนีในตารางนั้นมีเพียง 6 ดัชนีเท่านั้นที่ใช้ (สถิติแสดงให้เห็นว่ามีจำนวนการเข้าศูนย์ถึง 4 ของดัชนี) นี่เป็นระบบขนาดใหญ่ที่มีผู้พัฒนามากกว่า 20 คนเข้าร่วม ดัชนีถูกสร้างขึ้นด้วยเหตุผลใดก็ตามและอาจไม่ได้ใช้อีกต่อไป

เราจำเป็นต้องสนับสนุน SQL Server 2008 เนื่องจากเป็นสิ่งที่ฐานข้อมูลการทดสอบทำงานอยู่ แต่ลูกค้าทั้งหมดในปี 2014 และ 2016

นึกถึงการออกแบบดัชนีเช่นสวิตช์เลื่อน คุณสามารถย้ายปุ่มเปลี่ยนรูปสามเหลี่ยมสีแดงนี้ได้ทุกที่ตามแนวที่คุณต้องการ:

ฉันมักจะไม่วัดในแง่ของขนาด - ฉันมักจะคิดในแง่ของปริมาณดัชนี แต่ขนาดจะดีเช่นกัน

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

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

จุดเริ่มต้นของฉันมักจะ 5 และ 5:ประมาณ 5 ดัชนีต่อตารางโดยมี 5 หรือน้อยกว่าฟิลด์ต่อดัชนี ไม่มีอะไรมหัศจรรย์เกี่ยวกับหมายเลขนั้น - มันมาจากความจริงที่ว่าฉันมี 5 นิ้วในแต่ละมือดังนั้นมันจึงง่ายต่อการจับมือและอธิบายกฎ

คุณอาจต้องมีดัชนีน้อยกว่า 5 เมื่อภาระงานของคุณมีความเอนเอียงอย่างมากต่อการดำเนินการลบ / อัพเดต / แทรกและคุณไม่มีแรงม้าฮาร์ดแวร์เพียงพอที่จะติดตาม

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

ความปรารถนาที่จะมีมากกว่าดัชนี "The Ozar 5" บนโต๊ะอาจบ่งบอกว่าคุณมีข้อความค้นหาที่อ่านยากจำนวนมากในตาราง

ซึ่งอาจบ่งบอกว่าคุณสามารถได้รับประโยชน์จากดัชนี columnstoreแบบคลัสเตอร์หรือแบบไม่คลัสเตอร์บนตาราง

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

ดัชนี Columnstore ได้รับการออกแบบให้ทำงานในภาระงานหนัก OLTP กับ SQL Server 2016+ ดูเอกสารประกอบสำหรับการวิเคราะห์การดำเนินงานตามเวลาจริง

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

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

หากแบบสอบถามและ / หรือโครงสร้างข้อมูลไม่สามารถแก้ไขเพื่อให้บรรลุเป้าหมายได้ฉันคิดว่ามันมีให้เลือกสามแบบ

1. ดึงข้อมูลช้า
2. อัปเดตข้อมูลช้า
3. แหล่งข้อมูลฮาร์ดแวร์เพิ่มเติม $$$$

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

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

อย่างไรก็ตามมีหลายสิ่งที่ต้องพิจารณา:

• ดัชนีจำนวนมากทำให้การแทรก / อัพเดต / ลบช้าลง ดังนั้นหากตารางของคุณเปลี่ยนไปมากระวังอย่าทำมากเกินไป
• พื้นที่อาจเป็นปัญหาได้เช่นกัน ไม่เพียงเพราะกิกะไบต์มีค่าใช้จ่าย (ไม่มากในปัจจุบัน) แต่ยังมีเวลาเนื่องจากการสำรองข้อมูลจะช้าลง (ขึ้นอยู่กับวิธีการสำรองข้อมูล)
• ฐานข้อมูลที่ร้ายแรงที่สุดสามารถตรวจสอบเพื่อค้นหาดัชนีที่ไม่ค่อยหรือไม่เคยใช้ ลองทิ้งบางส่วน
• บางครั้งคุณคิดว่าคุณต้องการดัชนี แต่เมื่อคุณตรวจสอบคำถามของคุณให้ละเอียดยิ่งขึ้นคุณสามารถปรับแต่งและเขียนใหม่แตกต่างกันด้วยผลลัพธ์เดียวกันโดยไม่ต้องใช้ดัชนี ใช้อธิบายแผนเพื่อดูว่ามีการใช้ดัชนีหรือไม่
• บางครั้งคอลัมน์สุดท้ายอาจถูกลบจากดัชนีหลายคอลัมน์โดยไม่มีการเข้าชมมาก และบางครั้งสิ่งนี้สามารถสร้างคิวรีได้เร็วขึ้นเนื่องจากพื้นที่จัดเก็บดัชนีมีขนาดเล็กลงและดัชนีจำนวนมากจะถูกเก็บไว้ / แคชในหน่วยความจำ ณ เวลาใดก็ตาม
• ดัชนีฟังก์ชั่นที่ใช้สามารถแทนที่คนปกติเพื่อประหยัดพื้นที่มากขึ้น ตัวอย่าง: แทนการสอบถามนามสกุลเต็มแบบสอบถามสำหรับตัวอักษรสองตัวแรกยัง ( where substr(surname, 1, 2) = substr(<userinput>, 1, 2) and surname=<userinput>) create index i on customers(substr(surname,1,2))และ สิ่งนี้อาจเร็วพอและดัชนีของคุณจะเล็กลง
• ฐานข้อมูลรองรับดัชนีประเภทต่าง ๆ บางประเภทใช้พื้นที่น้อยกว่าประเภทอื่น บางทีดัชนีบางส่วนของคุณสามารถแปลงเป็นประเภทที่ใช้พื้นที่น้อยได้หรือไม่ ให้แน่ใจว่าได้เข้าใจประเภทดัชนีที่แตกต่างกันก่อนและสิ่งที่พวกเขาจะดีและไม่ดีสำหรับสถานการณ์
• หากงานแบ็ตช์ไม่บ่อยนักเป็นสิ่งเดียวที่ต้องการดัชนีที่เฉพาะเจาะจงให้พิจารณาสร้างดัชนีนั้นสำหรับงานแบ็ตช์นั้นเท่านั้นและวางลงในภายหลัง