เวอร์ชัน: SQL Server 2008 R2 Enterprise Edtn (10.50.4000)
ในความพยายามที่จะประเมินกลยุทธ์การแบ่งพาร์ติชันของฉันฉันเขียนแบบสอบถามนี้เพื่อรับวิธีการเข้าถึงกับดัชนีในพาร์ติชัน (ในความหมายกว้างที่สุดของคำแม้ว่าฉันจะกำจัดกอง) ในขณะที่ฉัน จำกัด การโฟกัสไปที่ตารางที่แบ่งพาร์ติชันฉันเชื่อว่าฉันต้องมองrange_scan_countและsingleton_lookup_countแต่ก็มีช่วงเวลาที่ยากลำบากในการกำหนดแนวคิด
SELECT
t.name AS table_name,
i.name AS index_name,
ios.partition_number,
leaf_insert_count,
leaf_delete_count,
leaf_update_count,
leaf_ghost_count,
range_scan_count,
singleton_lookup_count,
page_latch_wait_count ,
page_latch_wait_in_ms,
row_lock_count ,
page_lock_count,
row_lock_wait_in_ms ,
page_lock_wait_in_ms,
page_io_latch_wait_count ,
page_io_latch_wait_in_ms
FROM sys.dm_db_partition_stats ps
JOIN sys.tables t
ON ps.object_id = t.object_id
JOIN sys.schemas s
ON t.schema_id = s.schema_id
JOIN sys.indexes i
ON t.object_id = i.object_id
AND ps.index_id = i.index_id
OUTER APPLY sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) ios
WHERE
ps.object_id = ios.object_id
AND ps.index_id = ios.index_id
AND ps.partition_number = ios.partition_number
and ps.index_id = ios.index_id
and ps.partition_number = ios.partition_number
and s.name <> 'sys'
and ps.index_id <> 0 ;
เอาต์พุตที่เกี่ยวข้อง (เนื่องจากช่องว่างในการจัดรูปแบบตารางของ SO นี่เป็นตัวอย่างของคอลัมน์ 9 คอลัมน์แรกจากแบบสอบถามด้านบนโดยมีสองคอลัมน์สุดท้ายอยู่range_scan_countและsingleton_lookup_countตามลำดับ):
╔════════╦═════════════════╦════╦═══╦═══╦═══╦═══╦════════╦══════════╗
║ datetb ║ idx_datetb_col ║ 1 ║ 0 ║ 0 ║ 0 ║ 0 ║ 205740 ║ 3486408 ║
║ datetb ║ idx_datetb_col ║ 2 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 1079649 ║
║ datetb ║ idx_datetb_col ║ 3 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 1174547 ║
║ datetb ║ idx_datetb_col ║ 4 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 2952991 ║
║ datetb ║ idx_datetb_col ║ 5 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 3974886 ║
║ datetb ║ idx_datetb_col ║ 6 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 2931450 ║
║ datetb ║ idx_datetb_col ║ 7 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 3316960 ║
║ datetb ║ idx_datetb_col ║ 8 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 3393439 ║
║ datetb ║ idx_datetb_col ║ 9 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 3735495 ║
║ datetb ║ idx_datetb_col ║ 10 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 4803804 ║
║ datetb ║ idx_datetb_col ║ 11 ║ 0 ║ 0 ║ 0 ║ 0 ║ 29617 ║ 7655091 ║
║ datetb ║ idx_datetb_col ║ 12 ║ 1 ║ 0 ║ 0 ║ 0 ║ 174326 ║ 47377226 ║
╚════════╩═════════════════╩════╩═══╩═══╩═══╩═══╩════════╩══════════╝
ฉันเห็นความเป็นไปได้ที่แตกต่างกันเล็กน้อย แต่ฉันต้องการทิศทางเกี่ยวกับวิธีคิดเกี่ยวกับสิ่งนี้ (แน่นอนว่าฉันกำลังใช้วิธีนี้ในการ " อาจ " เพราะฉันรู้ว่า "มันขึ้นอยู่กับ" แต่ฉันก็กำลังมองหาความเข้าใจทางแนวคิดด้วย)
- ค่าที่คล้ายกันสำหรับพาร์ติชันทั้งหมด
range_scan_countอาจบ่งบอกว่าเราไม่ได้รับการกำจัดพาร์ติชันที่ดีเพราะเราสแกนพาร์ทิชันทั้งหมดในจำนวนเท่า ๆ กัน - ค่าที่แตกต่างกันสำหรับพาร์ติชันทั้งหมดที่
singleton_lookup_countมาพร้อมกับค่าที่ต่ำกว่าอย่างมากสำหรับrange_scan_countอาจบ่งบอกถึงการกำจัดพาร์ติชันที่ดีเนื่องจากเรากำลังสแกนน้อยกว่าที่เรากำลังค้นหา - ?
นี่คือความคิดของฉัน ฉันหวังว่าจะมีใครบางคนชั่งน้ำหนักเกี่ยวกับวิธีที่ฉันสามารถใช้ข้อมูลนี้หรือชุดข้อมูลอื่นเพื่อพิจารณาว่าตารางใดน่าจะได้รับประโยชน์มากที่สุดจากการแบ่งพาร์ติชันตามดัชนี
แก้ไข
นี่คือ DDL ที่ถูกตัด:
CREATE TABLE [dbo].[date_table](
[date_id] [int] NOT NULL,
[calendar_date] [datetime] NULL,
[valdate] [datetime] NULL,
CONSTRAINT [PK_datedb] PRIMARY KEY CLUSTERED
(
[date_id] ASC
) ON [partschm]([date_id]);
CREATE UNIQUE NONCLUSTERED INDEX [idx_datetb_col] ON [dbo].[date_table]
(
[calendar_date] DESC,
[date_id] ASC
) ON [partschm]([date_id])
GO