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

Question

我试图看到列存储索引可以在表上提供的性能提升。该表有大约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语句如下：

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倍。

我不明白添加主键如何会影响以压缩格式存储数据的列存储索引的查询性能。主键也只改变页面的顺序，在这种情况下，它们将是无。

以下是执行计划

Answer 1

密钥的存在会改变列存储构建的方式。因为构建器按顺序获取其输入，所得到的段是更好的段消除候选者。阅读更多Ensuring Your Data is Sorted or Nearly Sorted by Date to Benefit from Date Range Elimination：

  

数据仓库查询中最常见的过滤器类型是按日期。如果系统可以通过查看段中列的最小值和最大值来确定没有行符合条件，则列存储段删除可帮助您跳过整个一百万行段。因此，您通常希望确保按日期对细分进行排序或近似排序，以便尽可能快地执行日期过滤。

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