有关大型SQL Server数据库设计的建议

我们正在MSSQL 2008 R2 Standard中创建一个数据库，该数据库将存储大量记录。我们每年在一张表中估计有2亿多条记录，而我们主要是在插入数据时很少进行UPDATE或DELETE操作。它是一个数据存档系统，我们每天都在其中插入历史记录。我们将根据用户要求在此历史记录上生成不同类型的报告，因此我们有些顾虑，需要技术投入和建议。

• 管理此类存档表和数据库的最佳方法是什么？

这是我的意见：

1. 如果更新/删除很少，则可以将页面填充系数提高到95％。这样可以节省空间和读取数据。虽然做一些测试。
2. 根据年份（例如年份）对表进行分区。
3. 将这些分区放在不同的文件组上。

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

这里没有足够的信息来提供具体的建议。如果您认为需要详细的设计和实施方面的帮助，请考虑聘请人员。

• 确保您的设计使插入物始终位于表格的末尾。提示聚集索引。

• 只有很少的非聚集索引支持您需要执行的报告，以将它们保持在最低水平。这些报告是预先生成的吗？如果是，则考虑以下问题：如果生成报告需要2个小时（没有索引）或1分钟（有索引），可以吗？也许可以让报告花2个小时减少一个索引吗？或者可能不是？如果报告生成得不好，那将是另一个问题，因为用户不愿意等待，您可能需要实现更多索引来支持报告。

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