为什么表上主键的存在可以显着提高列存储索引的性能？

我试图了解列存储索引可以在表上提供什么样的性能提升。该表大约有 370 万行、11 列，并存储为堆（即没有主键）。我在表上创建列存储索引并运行以下查询：

SELECT 
    [Area], [Family],
    AVG([Global Sales Value]) AS [Average GlobalSalesValue],
    COUNT([Projected Sales])
FROM 
    dbo.copy_Global_Previous5FullYearSales
WHERE 
    [Year] > 2012  
GROUP BY 
    [Area], [Family]

创建表语句如下：

CREATE TABLE [dbo].[copy_Global_Previous5FullYearSales]
(
    [SBU] [NVARCHAR](10) NULL,
    [Year] [INT] NULL,
    [Global Sales Value] [MONEY] NULL,
    [Area] [NVARCHAR](50) NULL,
    [Sub Area] [NVARCHAR](50) NULL,
    [Projected Sales] [MONEY] NULL,
    [Family] [NVARCHAR](50) NULL,
    [Sub Family 1] [NVARCHAR](50) NULL,
    [Sub Family 2] [NVARCHAR](50) NULL,
    [Manufacturer] [NVARCHAR](40) NULL,
    [rowguid] [UNIQUEIDENTIFIER] NOT NULL,
    [ID] [INT] IDENTITY(1,1) NOT NULL,

    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]

在这种情况下，我从列存储索引获得的性能提升可以忽略不计。使用列存储索引的查询运行速度几乎与不使用索引的原始查询一样慢，在某些情况下甚至更慢，即使也使用批处理模式。

令人惊讶的是，当我在现有表上创建不断增加的主键 - ID 并重建列存储索引时，CPU 时间提高了 15 倍，运行时间提高了 3 倍。

我不明白添加主键如何影响以压缩格式存储数据的列存储索引的查询性能。此外，主键仅更改页面的顺序，在本例中，不会更改页面的顺序。

Below is the execution plan

键的存在改变了列存储的方式built。因为构建器按顺序获取输入，所以结果段是段消除的更好候选者。阅读更多内容确保您的数据已按日期排序或接近排序，以便从日期范围消除中受益 http://social.technet.microsoft.com/wiki/contents/articles/5718.ensuring-your-data-is-sorted-or-nearly-sorted-by-date-to-benefit-from-date-range-elimination.aspx:

数据仓库查询中最常见的过滤器类型是按日期。如果系统只需查看段中列的最小值和最大值即可确定没有行符合条件，那么列存储段消除可帮助您跳过整个一百万行段。因此，您通常需要确保片段按日期排序或接近排序，以便可以尽快执行日期过滤器。

您的订单是由ID但我很确定这会导致功能依赖性副作用。