我应该在什么时候拆分或分割一个很大但很简单的表

我们的网站上有一些大而简单的统计表（INT，INT，DATE）。每个表最多有300,000,000行，并且每天都在增加。

托管服务提供商建议我们拆分表或对表进行分区，而我在许多场合也看到了此建议。

然而...

我正在努力使建议与SQL Server的最大容量（数据库大小为524,272 TB）保持一致，而表行仅受“可用存储”限制。

根据这些数字，上述表格可以轻松地拥有数以百万计的行（10 等于 303的幂）。

啊哈，您可能会说，CAPABILITY和PERFORMANCE之间是有区别的。

但是，实际上在每个有关SQL Server性能的问题中，答案都是“这取决于表设计和查询设计”。

这就是为什么我问这个问题。桌子的设计再简单不过了。基于索引ID字段的简单count（*）操作查询也不能。

一般建议有一个原因，那就是它取决于表设计及其上的查询。我对您在Stack Exchange上其他帖子的回答也是如此。说“查询是基于索引ID字段的简单count（*）操作”并不能提供太多信息，因为它没有说明正在考虑的行集的基数。您可以采取的措施来缓解（截至目前为止）问题：

1. 分区。具体来说，您的数据似乎是日志类型的数据。我的猜测是，您希望按某个时间单位获取统计信息（例如“每天的小部件”或“按小时计的费用”）。按数量进行分区（在前面的示例中为几天或几小时），并偶尔将分区移至只读文件组

2. 与此相关的是，如果数据是一次写入，请考虑在该时间段不再处于活动状态时对数据进行预聚合。也就是说，如果该数据永远不会改变，为什么我要继续计算三年前一天中发生了多少事件？一天结束后，请计算当天的所有内容，将其存储在其他位置，再也不要计算了。实际上，如果您不再需要详细数据（即，您只对它进行汇总），请在计算后考虑将其删除。如果您实现了这种想法，那么过滤后的索引仅覆盖“活动”时间段就可以变得更加聪明，这将使您的查询更快，因为它们不会覆盖您的绝大多数数据

但是，正如我在另一篇文章中的建议所建议的那样，您肯定会知道的唯一方法是使用合理数量的数据加载并进行尝试。我们在这里所能做的就是说在一般情况下可能会起作用。没有您的硬件，数据和查询的详细信息，我们所能做的只是猜测。而且，您可能会发现，在运行测试后，我建议答案是“没有任何事情要做”，因为它按原样工作就可以了。

我将采用不同的方法，请注意，分区（在SQL Server中）主要是一种数据管理功能，查询性能可能是次要结果，具体取决于您如何管理它。^1个

如链接的文章所述，分区的主要好处是您可以使用分区切换来快速移动数据。例如，您可以将“较冷”的数据存档以降低存储速度，而将“较热”的数据保留在快速存储中。您可以按定期计划的时间间隔将数据滚动到存档分区，从而快速存档数据，而不必执行等待ETL执行传输的过程。但是，正如您对问题的早期评论之一所指出的那样，在实施此问题之前，需要进行一些仔细的考虑和计划。另外，根据您使用的SQL Server版本（企业版），您可以利用数据压缩来压缩单个分区。

就性能而言，您可以将锁升级更改为AUTO（默认值为TABLE），如下所示：

ALTER TABLE dbo.T1 SET (LOCK_ESCALATION = AUTO);
GO

此外，您可能会消除分区，但是查询模式将需要适应系统中非常具体且可重复的模式- 分区键和集群键以及所有唯一键变得相互连接，并且非常重要。如果这种平衡没有得到认可和设计，那么您将面临性能梦night。

随着SQL Server 2014的问世，您还可以利用增量统计信息，如果您主动监视和更新/创建大型表的统计信息，这将非常方便。

那么，应该在什么时候对表进行分区？这取决于查询工作量，数据的配置文件，但最重要的是，它取决于您绝对必须利用分区的哪些管理功能。分区不是为了查询性能，而是主要用于数据管理和管理。

在决定分区的大小之前，请考虑分区对查询计划的影响。从纯粹的性能角度来看，分区是粗粒度索引的一种形式。这可以提供额外的性能，但是它也是性能下降的来源，尤其是如果分区键未在所有查询中都出现时。从这里开始，我假设您已经完成了此家庭作业（看来您已经完成）。

关于所需分区大小的一个很好的经验法则是：大约是盒子上DRAM大小的一半。提出此建议的原因是：

1. 您可以在分区上重建索引，而不会浪费到tempdb。这比使用磁盘访问（甚至使用SSD）要快得多。
2. 进行此重建时，您仍然可以在DRAM中保留整个分区（通常是最新分区），以使查询性能保持良好状态。

换句话说，您要有足够的DRAM来容纳两个分区，并且分区的大小取决于运行的计算机。更大的机器可以舒适地处理更大的分区。

请注意，本指南还为 tempdb：至少最大分区的大小（因此，如果在重建索引时没有足够的DRAM，则可以将索引构建溢出到那里）。

您可能会考虑使用比这更小的分区大小，但是如果这样做，通常是为了优化性能而不是为了支持数据的可管理性。

您可以使用分区来玩很多其他技巧。例如，压缩，聚合或在只读分区上使用填充因子100。但是基本原理仍然是：设法使您管理的每个数据块都小于DRAM。

PS：很高兴看到您不接受“视情况而定”作为答案，请务必寻求获得答案的方法。

像其他几个功能一样，表分区经常被不恰当地使用（甚至可能是最经常使用的？）。@swasheck的回答已经很好地说明了我要给出的任何注意事项。

另外，要考虑的替代方法是分区视图。这是保持完全独立的表，但通过View中的UNION ALL将它们链接在一起的一种方法。每个表都需要一个“ CHECK CONSTRAINT”，以强制每个表保存哪些数据范围。优化器知道这种构造，并且应该仅使用View访问查询所需要的基础表（我不记得满足此要求的所有要求，因此请参阅底部的CREATE VIEW链接，但是我之前已经设置了它，使其按预期工作并不难）。

肯定有一些限制，主要缺点是，与表分区相比，它的透明性较差。但是，主要优点是这些表是单独的表，因此统计信息是完全分开的，而对于分区表，它们是针对整个表的（即使从SQL Server 2014开始，您也可以更新每个分区的统计信息）。

如果您不打算使用进出分区切换的方式，则应考虑使用此选项。特别是如果较旧的数据变化不大，因为保存较旧数据的表几乎不需要经常更新其索引/统计信息（或者如果该数据永不更改，则可能会更新）。

表分区的另一个经常被忽视/忽视的缺点是，从SQL Server 2012开始，在重建分区索引时，您将不再获得具有FULLSCAN的“免费”更新统计信息。您仍然可以通过在非分区索引上重建来获得此更新统计信息，在分区视图中表上的索引将为:)。

有关分区视图的更多信息，请检查出的MSDN页面CREATE VIEW，并查找在“备注”中的“分区视图”一节。