เป็นไปได้ไหมที่จะเพิ่มประสิทธิภาพการสืบค้นในตารางแคบ ๆ ที่มีแถวนับล้านแถว

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

คำค้นหา

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31'; 

โต๊ะ

CREATE TABLE [dbo].[Heartbeats](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [DeviceID] [int] NOT NULL,
    [IsPUp] [bit] NOT NULL,
    [IsWebUp] [bit] NOT NULL,
    [IsPingUp] [bit] NOT NULL,
    [DateEntered] [datetime] NOT NULL,
 CONSTRAINT [PK_Heartbeats] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

ดัชนี

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

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

UPDATE

เมื่อฉันเปลี่ยนแบบสอบถามเพื่อใช้คำใบ้ดัชนีบังคับแบบสอบถามดำเนินการใน 50ms:

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WITH(INDEX(CommonQueryIndex))
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 

การเพิ่ม DeviceID clause ที่เลือกอย่างถูกต้องยังส่งผลถึงช่วง 50ms:

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' AND DeviceID = 4;

ถ้าฉันเพิ่มลงORDER BY [DateEntered], [DeviceID]ในคิวรีดั้งเดิมฉันอยู่ในช่วง 50ms:

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 
ORDER BY [DateEntered], [DeviceID];

สิ่งเหล่านี้ใช้ดัชนีที่ฉันคาดหวัง (CommonQueryIndex) ดังนั้นฉันคิดว่าคำถามของฉันคือตอนนี้มีวิธีบังคับดัชนีนี้ให้ใช้กับแบบสอบถามแบบนี้หรือไม่? หรือขนาดของตารางของฉันลดลงจากเครื่องมือเพิ่มประสิทธิภาพมากเกินไปและฉันต้องใช้ORDER BYหรือคำใบ้?

เหตุใดเครื่องมือเพิ่มประสิทธิภาพไม่เหมาะกับดัชนีแรกของคุณ:

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

เป็นเรื่องของการเลือกของคอลัมน์ [DateEntered]

คุณบอกเราว่าตารางของคุณมี 44 ล้านแถว ขนาดแถวคือ:

4 ไบต์สำหรับ ID, 4 ไบต์สำหรับ ID อุปกรณ์, 8 ไบต์สำหรับวันที่และ 1 ไบต์สำหรับคอลัมน์ 4 บิต นั่นคือ 17 ไบต์ + 7 ไบต์ค่าใช้จ่ายสำหรับ (แท็ก, Null bitmap, var col offset, จำนวน col) รวม 24 ไบต์ต่อแถว

ที่จะแปลหน้า 140k เพื่อจัดเก็บ 44 ล้านแถวเหล่านั้น

ตอนนี้เครื่องมือเพิ่มประสิทธิภาพสามารถทำสองสิ่ง:

1. มันสามารถสแกนตาราง (การสแกนดัชนีคลัสเตอร์)
2. หรืออาจใช้ดัชนีของคุณ สำหรับทุกแถวในดัชนีของคุณจากนั้นจะต้องทำการค้นหาบุ๊กมาร์กในดัชนีคลัสเตอร์

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

ดังนั้นในกรณีนี้: 140k / 25% = 35000 แถว 140k / 33% = 46666 แถว

(@RBarryYoung, 35k คือ 0.08% ของแถวทั้งหมดและ 46666 คือ 0.10% ดังนั้นฉันคิดว่านั่นเป็นที่มาของความสับสน)

ดังนั้นหากส่วนคำสั่งของคุณจะส่งผลให้เกิดแถวระหว่าง 35000 ถึง 46666 (ซึ่งอยู่ใต้ส่วนคำสั่งด้านบน!) มีโอกาสมากที่จะไม่ใช้คลัสเตอร์ที่ไม่ใช่คลัสเตอร์ของคุณและจะใช้การสแกนดัชนีแบบกลุ่ม

สองวิธีในการเปลี่ยนแปลงเท่านั้น:

1. ทำให้ข้อที่เลือกของคุณมากขึ้น (ถ้าเป็นไปได้)
2. ดร็อป * และเลือกเพียงไม่กี่คอลัมน์เพื่อให้คุณสามารถใช้ดัชนีครอบคลุม

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

การเปลี่ยนจาก datetime เป็น smalldatetime เป็นการลดขนาดลง 16% ในดัชนีคลัสเตอร์และการลดขนาด 24% ในดัชนีที่ไม่ใช่คลัสเตอร์ของคุณ

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

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

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

แล้วจะทำอย่างไรดี?

คำแนะนำของฉันคือการลดดัชนี NC เปลี่ยน PK คลัสเตอร์เป็น nonclustered และสร้างดัชนีคลัสเตอร์บน [DateEntered] ง่ายกว่าดีกว่าจนกว่าจะได้รับการพิสูจน์เป็นอย่างอื่น

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

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)INCLUDE (ID, IsWebUp, IsPingUp, IsPUp)
 WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

ดังที่ฉันได้กล่าวไว้ในความคิดเห็นมันควรใช้ดัชนีนั้น แต่ถ้าคุณไม่สามารถโน้มน้าวให้ใช้คำสั่ง ORDER BY หรือดัชนีใบ้ได้

ฉันดูที่นี่แตกต่างออกไปเล็กน้อย

• ใช่ฉันรู้ว่ามันเป็นหัวข้อเก่า แต่ฉันสนใจ

ฉันจะทิ้งคอลัมน์วันที่และเวลา - เปลี่ยนเป็น int มีตารางการค้นหาหรือทำการแปลงสำหรับวันที่ของคุณ

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

สุดท้ายหากคุณสามารถใช้ SQL 2012 ได้ให้ลองใช้ SEQUENCE ซึ่งจะมีประสิทธิภาพเหนือกว่า identity () สำหรับส่วนแทรก