对超大表进行分区/索引

Question

我正在对大约 500 GB 的单个数据仓库表进行索引和分区。该表是一个堆，有一百多个TEXT列，并且TEXT_IN_ROW启用了该选项。这张桌子不是我设计的，我也没有能力在不久的将来改变它。

我的任务是对其进行分区。我们正在使用测试服务器上的数据库副本来解决这个问题。它每秒可以将大约 2 GB 的数据推送到 SSD RAID 阵列，因此 I/O 不是一个明显的瓶颈，它有 16 个内核（2 个 NUMA 节点）和 64 GB 的 RAM。

我的方法是禁用所有非聚集索引，创建分区函数和分区方案（大约 12 个分区，都在PRIMARY文件组上 - 他们使用它来启用滚动维护并为每晚 ETL 提供更多本地化插入，而不是分发我/O)，然后使用此分区方案为表构建聚集索引。

我正在创建聚集索引并对表进行分区，如下所示：

CREATE CLUSTERED INDEX CX_DailyTable ON DailyTable (LoadDate, SeqNumber) 
  WITH (SORT_IN_TEMPDB = ON) ON monthly_on_primary (LoadDate)

显然，这需要很长时间（到目前为止是 3 小时），而且我当然不希望它很快。让我稍微担心的是 tempdb 现在正在推动近 1 TB 并稳步攀升，尽管当前表的大小大约是这个大小的一半。我读过的 MS 文档建议 tempdb 空间使用量应该与最终表/聚集索引的大小有关。

如果 SORT_IN_TEMPDB 设置为 ON，则 tempdb 中必须有足够的可用空间来存储排序运行，并且目标文件组中必须有足够的可用空间来存储最终索引结构。排序运行包含索引的叶行。

他们的估计不正确吗？tempdb 是否不仅仅用于排序运行？或者创建这个聚集索引以某种方式使表的大小加倍？（似乎不太可能；这是一个相当宽的表，我估计每行可以获得额外的 4-8 个字节，加上通过添加聚集索引获得的非叶页。）

Answer 1

我的方法是禁用所有非聚集索引 [...] 然后使用此分区方案为表构建聚集索引。

在堆上创建聚集索引会自动重建所有非聚集索引（甚至禁用的索引）。非聚集索引会被重建但不会被分区。假设所需的最终状态是具有对齐索引的分区聚簇表，将非聚簇索引重建为非对齐完全是白费力气。

让我稍微担心的是 tempdb 现在正在推动近 1 TB 并稳步攀升，尽管当前表的大小大约是这个大小的一半。我读过的 MS 文档建议 tempdb 空间使用量应该与最终表/聚集索引的大小有关。

排序空间的问题非常复杂。要了解所有细节（包括并行性的影响），您需要仔细阅读SQL Server 查询处理团队的整个系列文章。将堆转换为启用并行性的分区聚簇表可能非常接近最坏的情况。

在最基本的情况下（忽略 QP 团队帖子中的大部分重要信息），您要求 SQL Server 运行如下查询：

SELECT *
FROM DailyTable
ORDER BY
    $partition.monthly_on_primary(LoadDate),
    LoadDate,
    SeqNumber;

无论您选择将不适合内存的排序运行写入何处，此查询都不会快速执行。再加上在单独的行集中实际构建整个数据集的完整新副本的工作，以及无意义地重建非聚集索引所涉及的工作......

要使此更改有效地工作，需要考虑许多因素。重要的是尽可能避免排序，并尽可能使用并行最小日志批量加载。

其细节取决于问题中未包含的细节，完整的解决方案超出了此处的答案。尽管如此，过去对我个人来说效果很好的方法的概述是：

每个分区的数据提取需要在上订购(LoadDate, SeqNumber)。理想情况下，您应该避免排序操作。如果您在 (LoadDate, SeqNumber) 上有一个现有的非聚集索引，如果您正确构造查询，则可以按正确的顺序提取数据而无需排序。

一旦每个分区的数据被提取到单独的文件中（如果你的硬件能够做到这一点，这可以并行完成），然后可以删除源表，释放空间。然后创建一个新的分区堆或集群表，并使用预先排序的数据批量加载，也可能并行加载。

如果做得好，整个过程只需要不超过 1 倍的数据大小，并在两个方向上实现最快的数据传输速率，同时使用最少的日志。