ฉันจะหาคำแนะนำเกี่ยวกับกลยุทธ์ดัชนีได้ที่ไหน


22

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

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


7
สำหรับคำแนะนำเกี่ยวกับการจัดทำดัชนีใช้
Mike Sherrill 'Cat Recall'

คำตอบ:


24

สั้น

กฎ "ดัชนีมากเกินไป" เป็นสิ่งที่ฉันคิดว่าทำให้เข้าใจผิด

ยาว

ระบุว่าฐานข้อมูลเฉลี่ยอยู่ที่ประมาณ 98% การอ่าน (หรือสูงกว่า) การอ่านจะต้องมีการปรับให้เหมาะสม INSERT เป็นการอ่านหากมีดัชนีที่ไม่ซ้ำกัน หรือตำแหน่งที่อัพเดต ฉันเคยอ่านว่าแม้แต่ฐานข้อมูลการเขียนที่เข้มข้นยังคงอ่านได้ 85%

สิ่งที่คุณทำคือการจัดทำดัชนีคุณภาพต่ำ ตัวอย่าง:

  • ดัชนีคลัสเตอร์แบบกว้าง (SQL Server โดยเฉพาะ)
  • การจัดทำดัชนีแบบไม่ใช้โมโนโทนิก
  • ดัชนีที่ทับซ้อนกัน (เช่นcold, coleและcold, cole, colf)
  • ดัชนีคอลัมน์เดี่ยวจำนวนมาก (ทับซ้อนกับดัชนีที่มีประโยชน์มากกว่า) ซึ่งไร้ประโยชน์สำหรับการสืบค้นของคุณ
  • ไม่มี INCLUDE ไม่ครอบคลุม (เช่นดัชนีคอลัมน์เดี่ยวทั้งหมด)
  • ...

โปรดทราบว่าเป็นเรื่องปกติที่จะมีดัชนีใหญ่กว่าข้อมูลจริงของคุณหลายเท่าแม้ในระบบ OLTP

โดยทั่วไปฉันจะเริ่มต้นด้วย

  • ดัชนีคลัสเตอร์ (ปกติคือ PK)
  • ดัชนีที่ไม่ซ้ำกัน (ไม่ใช่ข้อ จำกัด สิ่งเหล่านี้ไม่สามารถครอบคลุมได้)
  • คอลัมน์คีย์ต่างประเทศ

จากนั้นฉันจะดู:

  • ข้อความค้นหาทั่วไปและดูสิ่งที่ฉันต้องการ แบบสอบถามที่รันทุก ๆ วินาทีต้องการการปรับแต่ง รายงานเมื่อวันอาทิตย์เวลา 04.00 น. สามารถรอได้
  • ด้วย SQL Server ดัชนี DMV ที่ขาดหายไปของถ่วงน้ำหนัก

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


2
คุณได้รับหมายเลขเหล่านั้นจากที่ใด 98% ดูเหมือนชะมัดสูงโดยเฉพาะอย่างยิ่งในยุคของ "ข้อมูลขนาดใหญ่" (หรือร้านค้าทุกอย่างและหวังว่ามันจะมีประโยชน์บางวัน)
RM

7

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


7

ค่อนข้างเป็นหนึ่งในบทความที่ดีที่สุดของบทความที่เขียนว่าควรเลือกดัชนีอย่างไรและทำไม Gail Shaw คุณสามารถค้นหาบทความโดยคลิกที่นี่

คำถามที่คุณถามสามารถตอบได้ 50 วิธี จริงๆแล้วข้อมูลทั้งหมดที่คุณได้รับนั้นจะถูกนำไปสอบถามและสอบถามข้อมูลได้อย่างไร กฎทั่วไปคือคุณควรมีดัชนีคลัสเตอร์ในแต่ละตารางเพื่อหลีกเลี่ยงการกอง ดัชนีแบบคลัสเตอร์ควรมีขนาดเล็กที่สุดเท่าที่จะทำได้ หากตารางมีดัชนีคลัสเตอร์บันทึกดัชนีทั้งหมดในหน้าใบไม้ของดัชนีที่ไม่ได้ทำคลัสเตอร์จะจัดเก็บค่าบันทึกของดัชนีคลัสเตอร์ที่เกี่ยวข้องสำหรับการค้นหาบุ๊คมาร์ค หากตารางเป็นฮีป SQL จะสร้างตัวระบุเฉพาะสำหรับการค้นหาบุ๊กมาร์ก ฉันจำขนาดไม่ได้ว่าเป็น 8 หรือ 16 ไบต์ นี่อาจเป็นประเภทข้อมูลที่มีขนาดใหญ่กว่านั้นก็บอกว่าเป็น INT ลองนึกภาพว่ามี 8 ดัชนีที่ไม่ได้ทำคลัสเตอร์บนตารางฮีป


เพียงหมายเหตุถึงผู้อ่าน: MS SQL "การค้นหาบุ๊กมาร์ก" เทียบเท่ากับ "ACCESS BY ROWID" ของ Oracle ดู stackoverflow.com/a/820731/122727
kubanczyk

5

ฉันต้องการเพิ่มที่นี่ที่ฐานข้อมูลต่าง ๆ ต้องใช้กลยุทธ์ที่แตกต่างกัน ลองเปรียบเทียบ MySQL กับ w / InnoDB และ PostgreSQL

InnoDB

ตาราง InnoDB นั้นเป็นดัชนี b-tree ของคีย์หลักซึ่งขยายเพื่อรวมข้อมูลแถวในรายการดัชนี ไม่รองรับการสแกนตามลำดับจริงและการสแกนทั้งหมดเกิดขึ้นตามลำดับตรรกะ นี่หมายถึงสองสิ่ง:

  1. การสแกนตามลำดับใน Innodb สร้างดิสก์ I / O แบบสุ่มจำนวนมากและ

  2. ดัชนีคีย์หลักต้องถูกสำรวจโดยไม่คำนึงว่าจะใช้ดัชนีรองหรือไม่

  3. การค้นหาคีย์หลักนั้นเร็วกว่าในรุ่นนี้มากกว่าวิธีอื่น ๆ

ในกรณีนี้มันเป็นสิ่งสำคัญมากในการสร้างดัชนีฟิลด์ที่เพียงพอในตารางแบบหลายหน้า กฎทั่วไปคือดัชนีทุกสิ่งที่คุณต้องการกรอง

PostgreSQL

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

คีย์หลักใน PostgreSQL นั้นเป็นชุดย่อยของดัชนีเฉพาะที่ไม่มีค่าใด ๆ อาจเป็น NULL ข้อ จำกัด UNIQUE เสร็จสิ้นโดยใช้ดัชนีโดยนัยและประเภทดัชนีอื่น ๆ อีกมากมายได้รับการสนับสนุนโดยมีการดำเนินการที่แตกต่างกันในดัชนี

หมายความว่า:

  1. การค้นหาคีย์หลักสมมติว่า tablerequire ที่มีขนาดใหญ่พอสมควรกดปุ่มไฟล์ดัชนีและไฟล์ตาราง สิ่งนี้ช้ากว่าวิธีของ MySQL อย่างมากโดยที่ดัชนีจะต้องถูกสำรวจและแถวนั้นจะอยู่ในดัชนี

  2. การสแกนตามลำดับจริงทำได้ดีกว่ามากลดการสุ่มดิสก์ I / O ซึ่งจะต้องประมวลผลจำนวนแถวที่สำคัญ

  3. การสแกนดัชนีรองทำได้ดีกว่า MySQL เนื่องจากมีเพียงดัชนีเดียวเท่านั้นที่จะต้องผ่านเพื่อไปที่ส่วนทางกายภาพของตาราง

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

TL; DR

รู้จัก RDBMS ของเจ้า


4

จากคู่มือแนวคิด Oracle 11.2:

จากคู่มือการปรับแต่งประสิทธิภาพ 11.2:

จากคู่มือผู้ดูแลระบบ 11.2:


2

แม้จะมีลิงก์ข้างต้นทั้งหมด แต่คุณต้องดูว่า Kimberly Tripp เขียนเกี่ยวกับการดูแลการให้อาหารและการใช้ดัชนีอย่างไร

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

มีข้อมูลมากมายที่นี่ แต่อย่าครุ่นคิดเลย

หน้าเกี่ยวกับของ Kimberly อยู่ที่นี่


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