Hun*_*rX3 17 sql-server-2008 database-design partitioning
我有一个关于 SQL Server 2008 表设计的一般问题。我们目前有一个超过 600GB 的表，并且每天增长大约 3GB。此表具有适当的 indecies，但在运行查询时正成为主要问题，并且仅因为它的大小。问题是我应该按年和月将表拆分为多个表（这将适合其他部门拆分其大数据集的方式）还是我们应该利用 SQL Server 中内置的分区。使用分区似乎需要较少的代码更改。根据我在分区时阅读的内容，您仍然只查询一张表，服务器处理如何获取数据。如果我们走多表路线，我们将不得不处理从多个表中提取数据。
Bre*_*zar 11
“此表具有适当的 indecies，但在运行查询时正在成为主要问题”
除非 SQL Server 能够在运行查询时消除分区，否则单独分区并不能提高查询性能。您的 WHERE 子句需要与您的分区方式保持一致。我们只让一个字段用作分区字段，因此如果该字段未包含在您的 WHERE 子句中，尽管有分区，您仍然可能扫描整个表。
“而且只是因为它的大小。”
分区可以使某些维护操作更容易，但是我们仍然无法逐个分区地做一些事情。如果索引维护和统计更新给您带来问题，您最好将设计拆分为存档表和实时更新表。当您需要定期将数据从活动表移动到存档表时，您可以这样做，使用 100% 填充因子重建索引，使用完整扫描更新统计信息，然后将其文件组设置为只读。分区可以帮助归档表加载 - 但对活动表进行分区可能不会。（我在这里抛出几个高级概念，好像它既快速又简单，但我只是在这里勾勒出一些背景。）
“看起来使用分区需要更少的代码更改。”
有点 - 乍一看是这样，但是您越深入，就会有诸如分区视图之类的选项。您可以重命名现有表，在其位置放置一个视图，然后您可以在不更改应用程序的情况下对基础表进行自己的更改（并添加多个表）。
我在这里写了更多关于分区的陷阱：
http://www.brentozar.com/archive/2008/06/sql-server-partitioning-not-the-answer-to-everything/
单独分区可能就足够了，但通过结合分区视图和多个表可能会获得更好的结果。这在很大程度上取决于查询和增长的模式。
分区的当前限制是列统计信息仅在表中维护，而不是分区级别。如果您的查询模式可以从更准确的统计信息中受益，那么将表分区与分区视图相结合可以产生显着的性能优势。
如果数据的性质每月、每年都不同，分区视图也可以提供帮助。想象一家零售商不断改变其产品线，因此每年使用的 Product.ProductId 范围几乎没有一致性。使用单个 order/orderdetail 表以及单个统计直方图，统计信息对查询优化器的作用很小。按月分区并结合分区视图（Order、OrderLine）的每年表（Order_2010、Order_2011、OrderLine_2010、OrderLine_2011）将为优化器提供更细化且可能有用的统计数据。
您可以以相对较少的工作量引入表分区，因此从那里开始，测量影响，然后评估分区视图是否值得额外的努力。
Kimberly Tripp发表了许多关于分区的指南和白皮书，这些通常被认为是该主题的必读读物。Kendra Little也有一些很好的材料和其他文章的有用参考列表
性能通常是人们寻求分区的第一个原因。就个人而言，我认为恢复时间的改进与 VLDB 具有同等或更大的好处。在开始之前花一些时间了解部分可用性和零碎恢复，因为这可能会影响您采用的方法。
如果您有通过网络发送备份的不理想但并不少见的过程，您可能需要 3 小时才能恢复当前的 600GB。在您突破 1.5TB 的一年中，您遇到了问题。