Sql server 在包含350亿行的列存储索引表上重新创建索引

我有一个大表，我需要重建索引。该表配置了聚集列存储索引（CCI），我们意识到需要根据特定用例对数据进行排序

用户执行日期范围和相等性查询，但由于数据未按他们希望的方式排序，因此查询不是最优的。SQL咨询团队建议将数据组织在右行组中，以便查询可以从行组消除中受益

表说明：

• 按时间戳1分区，每月PF
• 总行数：310亿
• Est行大小：60字节
• Est表大小：600 GB

表定义：

CREATE TABLE [dbo].[Table1](
    [PkId] [int] NOT NULL,
    [FKId1] [smallint] NOT NULL,
    [FKId2] [int] NOT NULL,
    [FKId3] [int] NOT NULL,
    [FKId4] [int] NOT NULL,
    [Timestamp1] [datetime2](0) NOT NULL,
    [Measurement1] [real] NULL,
    [Measurement2] [real] NULL,
    [Measurement3] [real] NULL,
    [Measurement4] [real] NULL,
    [Measurement5] [real] NULL,
    [Timestamp2] [datetime2](3) NULL,
    [TimeZoneOffset] [tinyint] NULL
)

CREATE CLUSTERED COLUMNSTORE INDEX [Table1_ColumnStoreIndex] ON [dbo].[Table1] WITH (DROP_EXISTING = OFF)
GO

环境：

• SQL Server 2014企业版
• 8芯32 GB RAM
• VMWare High 表演平台

我的策略是：

删除现有的CCI

使用正确的列创建普通聚集行索引，这将对数据进行排序

使用DROP EXISTING=OFF重新创建CCI。这将把现有的CRI转换为CCI

我的问题是：

重建索引或只是重新加载数据有意义吗？重新加载可能需要一个月才能完成，而重建索引也可能需要同样多的时间，可能

如果我删除现有的CCI，表将扩展，因为它可能不再被压缩

---

310亿行是31000个完美的行组，行组只是另一个水平分区，所以何时以及如何加载数据非常重要。SQL 2014仅支持脱机索引生成

在考虑创建索引与重新加载时，有一些利弊：

• 创建索引是一个单独的操作，所以如果在任何时候失败，您都会失去进度。我不建议以您的数据大小使用它
• 索引构建将创建主字典，因此对于低基数字典编码列是有益的
• 批量加载不会创建主词典，但如果由于某种原因批处理失败，则可以重新加载数据

如果您提供足够的资源，索引构建和批量加载都将是并行的，这意味着您对基本聚集索引的排序不会得到完美保留，这只是需要注意的一点；在您的数据范围内，如果有几个重叠的行组，这并不重要

如果您的数据将进行更新/删除，并且您重新组织（从SQL19也将执行元组移动器），您的排序可能会随着时间的推移而降低

我会在

date\u range

列上创建一个有序的聚集索引和分区，这样每个分区就有50-200个行组（做一些实验）。然后，您可以创建一个分区对齐的聚集列存储索引，并一次在一个分区中切换，分区切换将触发索引生成，这样您就可以从主字典中获益。如果您最终在一个分区上进行更新/删除，您可以通过重建分区而不是整个表来修复索引质量。如果您决定使用reorganize，您仍然会保持某种级别的排序，因为行组只会合并到同一分区中