ณ จุดใดการมีดัชนีมีประสิทธิภาพ


9

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

มีใครรู้บ้างไหมว่าข้อ จำกัด นี้จะอยู่ที่ใดหรือรู้ถึงทรัพยากรที่ชี้ให้ฉันไปในทิศทางที่ถูกต้องหรือไม่?


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

คำตอบ:


12

ขีด จำกัด ที่แน่นอนนั้นยากที่จะกำหนดล่วงหน้า

สิ่งหนึ่งที่คนส่วนใหญ่ดูถูกดูแคลนคือความต้องการสูงที่ดัชนีจะต้องปฏิบัติตามก่อนที่จะกลายเป็นตัวเลือกที่จะใช้ในแบบสอบถาม

ดัชนีที่มีประสิทธิภาพ (ไม่เป็นคลัสเตอร์)

  • มีการเลือกที่ดีเช่นส่งกลับเพียงเปอร์เซ็นต์ที่น้อยมาก (<1%, <2%) ของแถวทั้งหมด หากการเลือกไม่ได้รับ - เครื่องมือเพิ่มประสิทธิภาพการสืบค้นของ SQL Server มักจะไม่สนใจดัชนีนี้

  • ควรครอบคลุมแบบสอบถามอย่างดีเลิศคือส่งคืนคอลัมน์ teh ทั้งหมดที่ต้องการโดยแบบสอบถาม หากคุณสามารถสร้างดัชนีที่มีคอลัมน์ดัชนี 1 หรือ 2 คอลัมน์และรวมคอลัมน์อื่น ๆ จำนวน 2-4 คอลัมน์ที่รวมอยู่ด้วยและทำให้คุณสามารถครอบคลุมคิวรีได้โอกาสที่เครื่องมือเพิ่มประสิทธิภาพคิวรีจะใช้ดัชนีนี้ ซึ่งหมายความว่า: หากรหัสของคุณใช้เสมอSELECT * .....เพื่อดึงข้อมูลคอลัมน์ทั้งหมดความน่าจะเป็นของดัชนีที่ใช้จะลดลงอย่างมาก

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

PS: ดัชนี nonclustered ในคอลัมน์คีย์ต่างประเทศเป็นกรณีพิเศษ ตามค่าเริ่มต้นฉันมักจะแนะนำให้เพิ่มสิ่งเหล่านี้เนื่องจากจะช่วยเร่งการตรวจสอบความสมบูรณ์ของการอ้างอิงทั้งสองรวมถึงJOINข้อ จำกัด FK เหล่านั้น แต่ถึงแม้ที่นี่จะสามารถใช้ "ขยาย" ดัชนี FK เหล่านั้นได้โดยการเพิ่มคอลัมน์ "รวม" เพิ่มเติมเพื่อให้มีประโยชน์มากยิ่งขึ้น


2
แม้ว่าคำตอบนี้อาจไม่ตอบคำถามโดยตรง แต่จะดีขึ้นมากโดยให้หลักการออกแบบที่สำคัญสำหรับดัชนีและตอบคำถามที่ฉันควรถามตั้งแต่แรก
SeanVDH

6

คุณอาจเห็นการปรับปรุงจากดัชนีที่มีเพียง 10 แถว

ในการทดสอบต่อไปนี้บนเครื่องของฉันรุ่นที่ไม่มีดัชนีเสร็จสมบูรณ์ในไม่10.5กี่วินาทีและรุ่นที่มีดัชนีเป็น9.8วินาที (สอดคล้องกันมากกว่า 3 วิ่ง)

ดัชนีในกรณีนี้ประกอบด้วย 1 leaf เพจ แต่เนื่องจากอาร์เรย์สล็อตถูกจัดเรียงตามลำดับคีย์ดัชนีการมีอยู่ทำให้ SQL Server เพิ่งส่งคืนแถวเดียวที่น่าสนใจแทนที่จะทำการรวมทั้งหมด 10

CREATE TABLE T
(
X INT,
Y CHAR(100) NULL
)

INSERT INTO T (X)
SELECT number 
FROM master..spt_values
WHERE type='P' AND number BETWEEN 1 AND 10

set nocount on;

DECLARE @I INT, @X INT

DECLARE @Time DATETIME2(7) = SYSUTCDATETIME()

SET @I = 1
    WHILE (@I < 1000000)
    BEGIN
    SELECT @X = MAX(X)
    FROM T
    SET @I += 1
    END

SELECT DATEDIFF(MICROSECOND, @Time, SYSUTCDATETIME())

CREATE CLUSTERED INDEX IX ON T(X)
SET @Time = SYSUTCDATETIME()
SET @I = 1
    WHILE (@I < 1000000)
    BEGIN
    SELECT @X = MAX(X)
    FROM T
    SET @I += 1
    END

SELECT DATEDIFF(MICROSECOND, @Time, SYSUTCDATETIME())

DROP TABLE T

เม็ดมีดได้รับผลกระทบในทำนองเดียวกันหรือช้าลงเล็กน้อยหรือไม่
SeanVDH

@SeanVDH - ตัวอย่างในคำตอบของฉันคือการเปรียบเทียบดัชนีคลัสเตอร์กับกอง เหตุผลที่แทรกระหว่างแถวที่มีอยู่จะช้าลงเนื่องจากแถวต้องเข้าไปในสถานที่ที่เฉพาะเจาะจงและการเขียนอาเรย์สล็อตอีกครั้งและความเป็นไปได้ของการแยกหน้า สำหรับการแทรกขนาดใหญ่ข้อมูลอาจถูกเรียงลำดับตามคำสั่งคีย์ CI ด้วยซึ่งไม่จำเป็นเมื่อทำการแทรกไปยังฮีป Kimberley Tripp โต้แย้งว่าที่นี่แม้ว่าบางครั้งการแทรกไปยัง CI อาจดีกว่าการใส่กอง
Martin Smith

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