คำถามติดแท็ก nonclustered-index

1
ทำไมดัชนีที่ไม่ได้จัดกลุ่มของฉันใช้พื้นที่มากขึ้นเมื่อฉันลบแถว
ฉันมีตารางขนาดใหญ่ที่มี 7.5 พันล้านแถวและ 5 ดัชนี เมื่อฉันลบประมาณ 10 ล้านแถวฉันสังเกตว่าดัชนีที่ไม่ได้จัดกลุ่มดูเหมือนจะเพิ่มจำนวนหน้าเว็บที่เก็บไว้ ฉันเขียนแบบสอบถามdm_db_partition_statsเพื่อรายงานความแตกต่าง (หลัง - ก่อน) ในหน้า: ดัชนี1เป็นดัชนีคลัสเตอร์ดัชนี2เป็นคีย์หลัก ส่วนอื่น ๆ นั้นไม่เป็นแบบคลัสเตอร์และไม่ซ้ำใคร เหตุใดหน้าต่างๆจึงเพิ่มขึ้นสำหรับดัชนีที่ไม่ใช่คลัสเตอร์เหล่านั้น ฉันคาดว่าตัวเลขจะแย่ที่สุดเหมือนกัน ฉันเห็นเคาน์เตอร์วัดประสิทธิภาพรายงานการเพิ่มขึ้นของการแยกหน้าระหว่างการลบ เมื่อลบแล้วระเบียนผีต้องย้ายไปหน้าอื่นหรือไม่ สิ่งนี้เกี่ยวข้องกับ "ตัวระบุเฉพาะ" หรือไม่ เรากำลังอยู่ระหว่างการเปิดตัว RCSI แต่ตอนนี้ RCSI ปิดอยู่ มันเป็นโหนดหลักในกลุ่มความพร้อมใช้งาน ฉันรู้ว่าสแน็ปช็อตนั้นใช้กับคนที่สอง ฉันจะแปลกใจถ้านั่นเกี่ยวข้อง ฉันวางแผนที่จะขุดลงในนี้ (ดูผลลัพธ์หน้า dbcc) เพื่อเรียนรู้เพิ่มเติม หวังว่าจะมีบางคนเห็นสิ่งที่คล้ายกัน

1
จำเป็นต้องรวมคอลัมน์ดัชนีคลัสเตอร์ในดัชนีที่ไม่ใช่คลัสเตอร์หรือไม่
เมื่อพิจารณาว่าดัชนีที่ไม่ได้ทำคลัสเตอร์นั้นเป็นไปตามดัชนีคลัสเตอร์ที่จำเป็นสำหรับดัชนีที่ไม่ทำคลัสเตอร์เพื่อแสดงรายการคอลัมน์ใด ๆ ที่มีอยู่ในดัชนีคลัสเตอร์หรือไม่ กล่าวอีกนัยหนึ่งถ้าตารางผลิตภัณฑ์มีดัชนีคลัสเตอร์บน ProductID เมื่อสร้างดัชนีที่ไม่ใช่คลัสเตอร์ซึ่งจะแนะนำให้รวมคอลัมน์ ProductID จำเป็นต้องเพิ่มอย่างไรก็ตามเป็นคอลัมน์หรือไม่? ถ้าไม่มีมีสถานการณ์ที่จะเป็นการดีที่จะเพิ่มชื่อคอลัมน์ไปยังดัชนีที่ไม่ใช่คลัสเตอร์หรือไม่

2
ทำไมดัชนีของฉันไม่ถูกใช้ใน SELECT TOP?
นี่คือการทำงานที่ลดลง: ฉันกำลังทำแบบสอบถามเลือก ทุกคอลัมน์ในWHEREและส่วนORDER BYคำสั่งจะอยู่ในดัชนีที่ไม่ใช่คลัสเตอร์IX_MachineryId_DateRecordedเดียวซึ่งเป็นส่วนหนึ่งของคีย์หรือเป็นINCLUDEคอลัมน์ ฉันกำลังเลือกคอลัมน์ทั้งหมดเพื่อที่จะส่งผลให้มีการค้นหาบุ๊กมาร์ก แต่ฉันกำลังทำอยู่TOP (1)ดังนั้นเซิร์ฟเวอร์จึงสามารถบอกได้ว่าการค้นหาจำเป็นต้องทำเพียงครั้งเดียวในตอนท้าย สิ่งสำคัญที่สุดคือเมื่อฉันบังคับให้แบบสอบถามใช้ดัชนีIX_MachineryId_DateRecordedมันจะทำงานในเวลาน้อยกว่าหนึ่งวินาที ถ้าฉันปล่อยให้เซิร์ฟเวอร์ตัดสินใจว่าจะใช้ดัชนีใดมันจะเลือกIX_MachineryIdและใช้เวลาประมาณหนึ่งนาที ที่แนะนำให้ฉันจริง ๆ ว่าฉันได้ทำดัชนีถูกต้องและเซิร์ฟเวอร์เพิ่งตัดสินใจไม่ถูกต้อง ทำไม? CREATE TABLE [dbo].[MachineryReading] ( [Id] INT IDENTITY (1, 1) NOT NULL, [Location] [sys].[geometry] NULL, [Latitude] FLOAT (53) NOT NULL, [Longitude] FLOAT (53) NOT NULL, [Altitude] FLOAT (53) NULL, [Odometer] INT NULL, [Speed] FLOAT (53) NULL, [BatteryLevel] INT …

1
NONCLUSTERED INDEX ที่ยังไม่ได้ใช้ยังสามารถเพิ่มความเร็วการสืบค้นได้หรือไม่?
นี่เป็นสถานการณ์ที่แปลก แต่ฉันหวังว่าบางคนจะมีคำตอบ ในบางช่วงการแก้ไขปัญหาประสิทธิภาพการทำงานของเราได้เพิ่ม nonclustered INDEX sp_BlitzIndexในตารางตามที่ได้รับการร้องขอจาก เราตรวจสอบการใช้งานในวันถัดไปและพบว่ามีการอ่าน0 ครั้ง (การสแกน 0 ครั้ง / การค้นหาการค้นหาเดี่ยว 0 ครั้ง ) ดังนั้นเราจึงปิดการใช้งาน ในนาทีถัดไปเราได้รับการร้องเรียนเกี่ยวกับแอพพลิเคชั่นช้า (ปัญหาประสิทธิภาพ) ที่เราพยายามตรวจสอบและแก้ไขในตอนแรกเมื่อเราเพิ่ม INDEX ทีนี้ฉันรู้แล้วในทางทฤษฎีฟังดูเป็นเรื่องบังเอิญอย่างแท้จริง ดัชนีถูกสรรพสิ่ง, วัด, ที่ไม่ได้ใช้ ปิดการใช้งานไม่ควรทำให้ประสิทธิภาพการทำงานของแบบสอบถามลดลง แต่มันเกือบจะบังเอิญเกินไป คำถาม ดังนั้นคำถามของฉันก็เพียงพอแล้ว: มันเป็นไปได้ทุกที่ , ว่า nonclustered INDEX ซึ่งมีการใช้งานสถิติ (จาก DMVs / การsp_BlitzIndex) แสดงการใช้งาน NO ยังคงได้รับการช่วยให้ประสิทธิภาพการค้นหาบนโต๊ะอย่างใดได้รับผลกระทบหรือไม่

3
ลำดับฟิลด์ในลำดับดัชนีคอมโพสิตที่มีการเลือกสูงและฟิลด์การเลือกต่ำ
ฉันมีตาราง SQL Server ที่มีมากกว่า 3 พันล้านแถว หนึ่งในคำถามของฉันใช้เวลานานมากดังนั้นฉันจึงพิจารณาที่จะเพิ่มประสิทธิภาพ แบบสอบถามมีลักษณะดังนี้: SELECT [Enroll_Date] ,Count(*) AS [Record #] ,Count(Distinct UserID) AS [User #] FROM UserTable GROUP BY [Enroll_Date] [Enroll_Date] เป็นคอลัมน์การเลือกต่ำที่มีค่าน้อยกว่า 50 ค่าในขณะที่คอลัมน์ UserID เป็นคอลัมน์เลือกสูงที่มีค่าแตกต่างกันมากกว่า 200 ล้านรายการ จากการวิจัยของฉันฉันเชื่อว่าฉันควรสร้างดัชนีคอมโพสิตแบบไม่รวมกลุ่มในสองคอลัมน์นี้และในทางทฤษฎีแล้วคอลัมน์การเลือกสูงควรเป็นคอลัมน์แรก แต่ฉันไม่แน่ใจว่าในกรณีของฉันจะทำงานได้เพราะฉันใช้คอลัมน์หัวกะทิต่ำในกลุ่มโดยข้อ ตารางนี้ไม่มีดัชนีคลัสเตอร์

2
การจัดเก็บที่อยู่ IP - varchar (45) vs varbinary (16)
ฉันจะสร้างตารางที่มีสองช่อง - IDเป็นBIGINTและIPAddressเป็นอย่างใดอย่างหนึ่งหรือvarchar(45) varbinary(16)แนวคิดคือการจัดเก็บที่อยู่ IP ที่ไม่ซ้ำกันทั้งหมดและใช้การอ้างอิงIDแทนจริงIP addressในตารางอื่น ๆ โดยทั่วไปฉันจะสร้างการจัดเก็บที่กลับมาIDสำหรับการรับIP addressหรือ (ถ้าอยู่ไม่พบ) IDแทรกอยู่และกลับที่สร้างขึ้น ฉันคาดหวังว่าจะมีบันทึกจำนวนมาก (ฉันไม่สามารถบอกได้อย่างชัดเจนว่ามีจำนวนเท่าใด) แต่ฉันต้องการขั้นตอนการจัดเก็บด้านบนเพื่อดำเนินการโดยเร็วที่สุด ดังนั้นฉันจึงสงสัยว่าจะเก็บที่อยู่ IP จริงไว้อย่างไรในรูปแบบข้อความหรือไบต์ อันไหนจะดีกว่ากัน? ฉันได้เขียนSQL CLRฟังก์ชันสำหรับแปลงที่อยู่ IP เป็นสตริงและย้อนกลับดังนั้นการแปลงจึงไม่ใช่ปัญหา (ทำงานกับทั้งสองIPv4และIPv6) ฉันเดาว่าฉันต้องสร้างดัชนีเพื่อปรับการค้นหาให้เหมาะสม แต่ฉันไม่แน่ใจว่าฉันควรรวมIP addressฟิลด์ไว้ในดัชนีกลุ่มหรือเพื่อสร้างดัชนีแยกต่างหากและการค้นหาประเภทใดจะเร็วขึ้น

3
เหตุใดเครื่องมือเพิ่มประสิทธิภาพจึงเลือกดัชนีที่เป็นกลุ่ม + เรียงลำดับแทนที่จะเป็นดัชนีที่ไม่ได้ทำคลัสเตอร์
รับตัวอย่างถัดไป: IF OBJECT_ID('dbo.my_table') IS NOT NULL DROP TABLE [dbo].[my_table]; GO CREATE TABLE [dbo].[my_table] ( [id] int IDENTITY (1,1) NOT NULL PRIMARY KEY, [foo] int NULL, [bar] int NULL, [nki] int NOT NULL ); GO /* Insert some random data */ INSERT INTO [dbo].[my_table] (foo, bar, nki) SELECT TOP (100000) ABS(CHECKSUM(NewId())) …

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