有谁知道 SQL Server 2008 中表大小的上限吗？我有个朋友想在一个表中保存大约 900,000,000 条记录。我对这些记录一无所知，也不知道这些记录的读取/更新量有多大。
显然，他们需要考虑索引和磁盘 IO，但我想知道是否有人有使用 SQL Server 2008 中非常大的表的经验，可以分享吗？
答案1
我有一个数据库，其中有一个表，目前有大约 18 亿条记录（是的，是 B，不是 M）。同一个数据库中还有另一个表，其中有大约 7.4 亿条记录。
总数据库大小约为 300GB。
服务器运行良好。它是四核 Xeon，配备 32GB RAM 和非常快的磁盘阵列。
至于技巧和窍门：
认真想想你为什么需要这么多数据。每次处理的数据量都很大。此外，一旦设置完成，就不用再更改索引、列或任何其他东西了。在这么大的表上完成这些操作需要很长时间。
认真想想你为什么需要这么多数据。是的，我又重复了一遍。如果可能的话，换一种方法。恢复这么大的数据库是一件非常麻烦的事情，可能需要长的时间……大概一天左右。
如果可能，请以某种有意义的方式汇总数据。如果使用数据进行趋势分析，请尽快完成计算并丢弃基础数据。当然，如果出于某种原因必须保留基础数据，请将其存储在平面文件或其他文件中。
不要对这种数据库大小使用任何形式的加密。如果您的数据需要加密，那么请计划花费很多硬件方面的资金投入（在 100 万美元以上的范围内）。
慢慢来，测试不同的恢复模型。甚至可以在交易过程中硬启动服务器。看看会发生什么。我发现“简单”对我来说最有效。
我的数据大多是事务性的，坦白说，并不是关键任务数据。如果整个数据库突然崩溃，那么，一些人可能会因为一些小事而感到惊讶。
数据库每秒处理大约 150 个请求。其中 99.999% 是写入。每晚，我们将获得的信息汇总到汇总表中。有一个小型仪表板网站，大约有 5 个人使用它来查看历史/每日摘要。
您真正想寻找的是什么样的信息？
答案2
这个MSDN文档说表大小“受可用存储空间限制”。我没有足够的 SQL Server 大表使用经验来为您提供任何性能指南，但是在不了解相关记录或读/写模式的情况下，我想其他人也帮不上忙。
答案3
按照任何标准，这都是很多记录。处理大量数据的技术有很多，但是……如果没有更多关于朋友正在尝试解决的问题的信息，任何人都不可能进一步发表意见。