如何解释这些DMV的结果以帮助我评估分区策略？

版本：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 ║
╚════════╩═════════════════╩════╩═══╩═══╩═══╩═══╩════════╩══════════╝

我看到了几种不同的可能性，但是我需要如何思考这个问题（当然，我在“ 可能 ”中介绍了这一点，因为我知道“取决于”，但是我也在寻找概念上的理解）：

1. 所有分区的相似值range_scan_count 可能表明我们没有很好地消除分区，因为我们扫描所有分区的次数大致相同。
2. 所有分区的值变化singleton_lookup_count较大，同时的值明显较低，这range_scan_count 可能表明良好的频繁分区消除，因为我们扫描的次数少于所要查找的次数。
3. ？

到目前为止，这些都是我的想法。我希望有人在考虑如何使用此信息或另一组信息来确定哪些表最有可能从完全放弃索引而放弃分区中受益。

编辑

这是剪辑的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

与其查看索引利用率，不如查看计划缓存以查找逻辑读取量最大的查询。通常，当我处理分区时，我会发现一些查询占主导地位的查询-总体上占服务器读取的50-80％。检查这些查询以查看它们是否已成功执行分区消除。

如果他们没有进行分区消除，但是您认为它们应该（基于分区方案），则应与查询编写器合作以消除分区。

如果他们没有消除分区，并且不能消除分区（由于查询的编写方式或分区的设计方式），那么该是时候开始提出棘手的问题了。

如果最大的逻辑读取查询与分区表没有任何关系，请继续关注其他查询。