小编Adr*_*rie的帖子

情况

• Sql Server 2008 Enterprise 上的数据仓库
• 36+ 万行堆（别问），60+ 列
• 每月增加 750k
• 没有定义主键（我现在已经确定了一个）
• 无压缩

我在想做什么（按此顺序）

• 添加页面级压缩
• 添加PK
• 添加多个非聚集索引
• 尽快执行此操作

题

• 最终：我是先添加 PK 还是页面压缩？（有关系吗？）
• 如果我先将压缩添加到表中，那么任何索引是否会继承表级压缩设置？这个特定问题的答案是“不，压缩不是继承的”，在 dba.stackexchange 上找到

我现在倾向于什么

-- Add page level compression
alter table     dbo.TableName
rebuild with    (data_compression = page)
; 
go

-- Add primary key
alter table             dbo.TableName
add constraint          PK_TableName
primary key clustered   (<Columns>)
;
go

-- Add NC_IXs here
...
...

我看过here（PK创建文档）和here（ALTER TABLE文档），但看不到任何关于是否有任何索引继承表压缩设置的明确信息。 这个特定问题的答案是“不，压缩不是继承的”，在 dba.stackexchange 上找到

SQL Cat 有一个技巧列表，标题为“构建大型关系数据仓库的 10 大最佳实践”。

在部分下，4 - Design dimension tables appropriately他们指出：

避免对维度表进行分区。

他们没有提到为什么不应该这样做，我也没有在网上找到任何明确指出为什么要避免这样做的内容。

为什么要避免对维度表进行分区？

下面提供了一个更具体的例子来帮助回答，并讨论为什么不应该在大型关系数据仓库中进行分区。我不是在寻求有关改进特定于具体示例的数据模型的建议。如果该示例没有帮助提供有关为什么不应该进行分区维度的任何额外见解，那么请忽略它。

示例：您可以在答案中引用为什么分区维度是一个糟糕的/次优的想法（如果对您有帮助的话）...

在我们的环境中，我们有一个Account维度，它被分区DateEffective并每月加载。我们的一些查询涉及WHERE DateEffective >= @ReportDate，这似乎是分区消除的一个很好的候选者。此外，如果我们需要重新加载当月的数据，我们将删除整个月的数据，这似乎也将从表分区中受益。

自发布问题以来更新我们的环境......

上面提到的表具有非对齐的非聚集索引（使用以下 Brent Ozar 代码进行调查）。

select
    [db_name]               = isnull(db_name(s.database_id),db_name())
    ,[schema_name]          = object_schema_name(i.object_id,db_id())
    ,[object_name]          = o.name
    ,index_name             = i.name
    ,index_type_desc        = i.type_desc
    ,data_space_name        = ds.name
    ,data_space_type_desc   = ds.type_desc
    ,s.user_seeks
    ,s.user_scans
    ,s.user_lookups
    ,s.user_updates
    ,s.last_user_seek
    ,s.last_user_update
from
    sys.objects as o

    inner join sys.indexes as i 
        on o.object_id = i.object_id …