ฟิลด์ INCLUDE ดัชนีขนาดใหญ่จะมีผลต่อประสิทธิภาพของระบบอย่างไร

15

คำถามนี้เป็นคำถามเกี่ยวกับประสิทธิภาพของดัชนี SQL Server กับvarchar(2000)เป็นINCLUDEในดัชนีที่ครอบคลุม

ฉันพยายามปรับปรุงประสิทธิภาพในแอปพลิเคชันฐานข้อมูลที่ช้าและไม่เสถียร ในบางกรณีข้อมูลที่มีการเข้าถึงผ่านสตริง varchar ขนาดใหญ่ที่มีการค้นหารวมทั้งการดำเนินสตริง multple เหมือนSUBSTRING(), และSPACE() DATALENGTH()นี่คือตัวอย่างที่ง่ายของการเข้าถึง

update fattable set col3 =  
   SUBSTRING(col3,1,10) + '*' + 
   SUBSTRING(col3,12,DATALENGTH(col3)-12)
from fattable where substring(col3,10,1) = 'A' and col2 = 2

สคีมามีลักษณะดังนี้:

CREATE TABLE [dbo].[FatTable]( 
    [id] [bigint] IDENTITY(1,1) NOT NULL, 
    [col1] [nchar](12) NOT NULL, 
    [col2] [int] NOT NULL, 
    [col3] [varchar](2000) NOT NULL, ...

มีการกำหนดดัชนีต่อไปนี้โดยมีฟิลด์ครอบคลุมในคอลัมน์ข้อความขนาดใหญ่

CREATE NONCLUSTERED INDEX [IndexCol2Col3] ON [dbo].[FatTable]  ( [col2] ASC ) 
    INCLUDE( [col3] )

จากสิ่งที่ฉันได้อ่าน BAD คือการวางเขตข้อมูลขนาดใหญ่ในดัชนี ฉันอ่านบทความต่าง ๆ รวมถึงhttp://msdn.microsoft.com/en-us/library/ms190806.aspxซึ่งพูดถึงผลกระทบของการเพจและขนาดดิสก์ต่อประสิทธิภาพของดัชนี สิ่งนี้ถูกกล่าวถึงแผนแบบสอบถามใช้ดัชนีครอบคลุมแน่นอน ฉันไม่มีข้อมูลเพียงพอที่จะพิจารณาว่านี่คือต้นทุนของฉันในแง่ของการโหลดระบบ ฉันรู้ว่าโดยรวมแล้วระบบทำงานได้ไม่ดีและฉันกังวลว่านี่เป็นหนึ่งในปัญหา คำถาม:

การวางvarchar(2000)คอลัมน์นี้ในดัชนีINCLUDEเคยเป็นความคิดที่ดีหรือไม่?
เนื่องจากINCLUDEฟิลด์จะถูกเก็บไว้ในโหนดใบไม้พวกมันมีผลกระทบต่อดัชนีประสิทธิภาพหรือไม่

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

— RaoulRubin
แหล่งที่มา

ค่าจริงเป็นเวลานานเท่าใด A VARCHAR(2000)ซึ่งโดยปกติเก็บเพียงสิบตัวอักษรเป็นสิ่งหนึ่ง; ทึบ 2,000 ไบต์ต่อบันทึกเป็นอย่างอื่น

— Jon of All Trades

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

— แกรม

1

ใช่ #Graeme มีกลิ่นเหม็นที่นี่ - ฉันคิดว่ามันเรียกว่า "มรดก" มีปัญหามากมายในฐานข้อมูลนี้

— RaoulRubin

14

เคยเป็นคำใหญ่ แต่โดยทั่วไปไม่ฉันจะไม่ใส่เขตข้อมูล varchar (2000) ลงใน INCLUDE

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

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

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

— Grant Fritchey
แหล่งที่มา

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

— RaoulRubin

1

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

— Grant Fritchey

6

คุณสามารถตรวจสอบคีย์ดัชนีคลัสเตอร์ปัจจุบันและอาจทำcol2คีย์ดัชนีคลัสเตอร์แทนได้หรือไม่ วิธีนี้คุณจะได้รับการทำงานแบบ 'รวม' (ตั้งแต่ดัชนีคลัสเตอร์อยู่เสมอ 'รวมถึง' ทุกอย่าง) โดยไม่มีการทำซ้ำข้อมูล แน่นอนเรื่องนี้ขึ้นอยู่กับหลาย ๆ คนifและbutอาจจะมีมูลค่าการพิจารณา แน่นอนถ้าดัชนีคลัสเตอร์ปัจจุบันมีการบังคับใช้ข้อ จำกัด (คีย์หลัก, ที่ไม่ซ้ำกัน) กล่าวว่าข้อ จำกัด จะต้องถูกย้ายไปยังดัชนีที่ไม่ได้ทำคลัสเตอร์

— Remus Rusanu
แหล่งที่มา

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

— RaoulRubin

4

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

— แอรอนเบอร์ทรานด์
แหล่งที่มา

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

— RaoulRubin

2

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

— Aaron Bertrand

3

ฉันรู้ว่าฉันมาสายสำหรับปาร์ตี้นี้ แต่ฉันจะจัดทำดัชนีนิพจน์ที่ใช้ในการค้นหาแถวเช่นซับสตริง (col3,10,1) อย่างแน่นอน หากใช้ col3 ทั้งหมดฉันจะทำดัชนี CHECKSUM (col3) (เข้าใจว่าอาจมีการชนกันของหลักสูตร)

— อลาสกา
แหล่งที่มา