C# 具有包含7亿条记录的表的数据库

可能重复：

---

我想创建一个.Net应用程序，它使用一个数据库，其中一个表中将包含大约7亿条记录。我想知道SQLite的性能是否能满足这种情况，还是应该使用SQL Server。我喜欢SQLite给我的可移植性。

一定要使用SQL Server。SQLite中的7亿条记录太多了

使用SQLite有以下限制

• 单进程写入
• 没有镜像
• 无复制

---

查看此线程：

SQLite应该能够处理这么多数据。但是，您可能必须对其进行配置，以允许其增长到这个大小，并且您不应该在SQLite的“内存中”实例中有这么多数据，这只是一般原则

有关更多详细信息，请参见其中解释了SQLite引擎的实际限制。相关的配置设置是页面大小（通常为64KB）和页面计数（最多64位int的最大值约为21亿）。计算一下，整个数据库可能会占用超过140TB的空间。一个数据库由一个700m行的表组成，大约有几十个Gig；易于管理

---

然而，仅仅因为SQLite可以存储那么多数据并不意味着您应该这样做。对于大型数据存储，SQLite的最大缺点是SQLite代码作为进程的一部分运行，使用调用它的线程并占用沙箱中的内存。您没有面向服务器的DBMS中可用的工具来“分而治之”大型查询或数据存储，如复制/集群。在处理这样的大型表时，插入/删除将花费很长时间才能将其放在正确的位置并更新所有索引。选择可能是可行的，但仅在索引查询中；页面或表格扫描绝对会让你丧命。

我有过记录计数相似的表格，在检索方面没有问题

首先，硬件和服务器分配是您可以开始的地方。参见以下示例：

无论记录的大小或数量，只要您：

• 在外键上创建索引
• 在视图中存储公共查询(http://en.wikipedia.org/wiki/View_%28database%29),
• 并定期维护数据库和表

你应该没事的。此外，为每列设置适当的列类型/大小也会有所帮助。

700m是一个很大的问题

给你一个主意。假设您的记录大小为4字节（基本上存储一个值），那么您的DB将超过2GB。如果您的记录大小接近100字节，则接近65GB。。。（这不包括索引和事务日志文件等使用的空间）

我们做了很多关于大型数据库的工作，我从来没有考虑过这样的大小。坦率地说，“可移植性”是您最不关心的问题。为了以任何响应方式查询该大小的数据库，您需要一个适当大小的数据库服务器。我从32GB的RAM和高速驱动器开始

如果它的写容量高达90%+，您可能会得到更小的RAM。如果它读起来很重，那么您需要尝试构建它，以便机器可以在RAM中加载尽可能多的DB（或至少索引）。否则，您将取决于磁盘主轴速度