大型SQL Server数据库设计建议

Question

我们正在 MSSQL 2008 R2 标准中创建一个数据库，我们将在其中存储大量记录。我们估计每年在一张表中有 2 亿多条记录，我们主要是在数据上进行极少更新或删除的插入。它是一个数据存档系统，我们每天都在其中插入历史记录。我们将根据用户请求生成关于此历史记录的不同类型的报告，因此我们有一些担忧并需要技术投入和建议。

• 管理这种归档表和数据库的最佳方法是什么？

Answer 1

这是我的意见：

1. 如果您的更新/删除很少，您可以将页面填充因子增加到 95%。这将节省空间和读取。不过做一些测试。
2. 根据诸如年份之类的广泛类别对表进行分区。
3. 将这些分区放在不同的文件组上。

Answer 2

每年 2 亿行并不是特别大（除非这些行异常大）。您需要注意健全的数据库设计原则（规范化）并利用索引和分区等标准功能。显然，正确的硬件也很重要。

这里没有足够的信息来提供具体的建议。如果您觉得在详细设计和实施方面需要帮助，请考虑雇用某人。

Answer 3

• 确保您的设计使您的刀片始终位于桌子的末端。提示聚集索引。

• 只有很少的非聚集索引支持您需要做的报告，以将它们保持在最低限度。这些报告是预先生成的吗？如果是，那么请考虑这个问题：生成报告需要 2 小时吗？（没有索引）或 1 分钟（有索引）。也许让报告用2个小时少一个索引就可以了？或者可能不是？如果报告没有很好地预先生成，这是另一个问题，因为用户不喜欢等待，您可能需要实施更多索引来支持您的报告。

• 从您描述这个数据库的方式来看，您似乎期望有很多行，并且数据会大量增加和增长。你考虑过如何备份这个系统吗？我想大多数数据都是一样的，只是添加新的？我不知道这个系统的业务要求，但对我来说，似乎在一两年内这可能是一个相当大的数据库，你可能无法进行许多完整备份。考虑使用定期（每周？）和差异（每天？）和事务日志（每小时？）进行一次完整备份。当然，正如我所说，我不知道业务需求，也许您不需要一直进行所有备份？大小可能是档案系统中的一个问题。