何时根据服务器上的内存量对 SQL Server 中的表进行分区

Question

我知道表分区主要是为了数据管理。我知道大表的表维护变得更加困难，因为例如索引重建不能适应内存或因为例如使用 O(n*log(n)) 对比例进行排序，这会导致大表出现额外问题。

有人可以举一些例子，相对于服务器上的内存量，一个表应该有多大才能成为分区的明确候选者？假设表大于 RAM 量。不分区表是不好的做法吗？

我正在寻找一些可以作为分析依据的原则。

在下面的答案中链接到的文章中，它还提到：

• 长期运行的索引维护作业（或无法在所有运行他们，因为他们会花这么长时间）的参考。

所以我想我的问题可以表述为：考虑到硬件规格，当 SQL Server 没有分区时，SQL Server 何时开始出现行存储索引重建问题？

我不相信“这与桌子的大小无关”。当索引无法重建时，我会说分区与表的大小非常相关。

Answer 1

没有真正的基于大小的公式来开始对表进行分区。不幸的是，它比这复杂得多。

性能与数据管理的切线

我会比说分区“主要用于数据管理”更强烈。我会说分区是一个数据管理功能——句号。有些人会看到性能优势，但这在与被迫完成分区对齐的编码和索引模式相关的某些场景中确实是一个附带优势。这些编码和索引模式本身通常会带来类似的好处。但这与您的实际问题有点不同。

重要的是分区是数据管理功能，而不是性能功能。

什么时候使用分区？

Kendra Little 写了一篇很棒的文章，标题是如何决定是否应该使用分区，我建议阅读它。它已经有几年的历史了，但仍然完全准确和相关。

总而言之，有一些关于数据管理（不是大小）的“故事”是采用分区的良好驱动因素。此外，任何大小的考虑通常都与分区的大小有关，而不是与整个数据的大小有关。

一些“教科书”的原因是：

• 有一个特定的键（例如日期窗口）用于标识数据的不同段（分区）。
• 在做 ETL/ELT 时，使用一个单独的/分区作为“登陆”点，然后SWITCH将该分区放入主表中。
• 清除旧数据时，按日期分区，以便可以通过截断/删除旧分区来清除旧数据，而不是使用DELETEs。
• 与存档数据相比，对“活动”数据使用不同的压缩级别。
• 不同数据段（例如活动与存档或其他分区键）之间的查询模式有所不同。

这只是我脑海中的一个快速列表，但不用说，这更多是关于你如何管理它，而不是具体关于大小。如果您使用与您的数据管理需求无关的任意键进行分区，您可能会在没有意识到任何好处的情况下获得大量复杂性。