具有大型数据库文件的sqlite的性能特征是什么？ [关闭]

#1 楼

因此，我使用sqlite对非常大的文件进行了一些测试，并得出了一些结论（至少对于我的特定应用程序而言）。

测试涉及一个带有单个表或多个表的sqlite文件。 。每个表大约有8列，几乎所有整数和4个索引。

其目的是插入足够的数据，直到sqlite文件大约为50GB。

单表

我试图在只有一个表的sqlite文件中插入多行。当文件约为7GB时（抱歉，我无法具体说明行数），插入时间太长。我估计插入所有数据的测试大约需要24小时，但即使在48小时后也无法完成。

这使我得出一个结论，即一个非常大的sqlite表会出现插入问题，并且可能还会发生其他操作。

我想这并不奇怪，因为该表会变大，插入和更新所有索引会花费更长的时间。

多个表

然后我尝试按时间将数据拆分到多个表中，每天一个表。原始1个表的数据被拆分为700个表。

由于每天都会创建一个新表，因此该设置在插入时没有问题，并且不需要花费较长的时间。

真空问题

正如i_like_caffeine所指出的那样，如果sqlite文件更大，则VACUUM命令是一个问题。随着更多插入/删除操作的完成，磁盘上文件的碎片会变得更糟，因此目标是定期进行VACUUM优化文件并恢复文件空间。

但是，正如文档所指出的那样，就需要对数据库的完整副本进行清理，这需要很长时间才能完成。因此，数据库越小，此操作将完成得越快。

结论

对于我的特定应用程序，我可能会每天将数据拆分成多个db文件，以获得真空性能和插入/删除速度的最佳效果。

这使查询复杂化，但是对于对我来说，能够对这么多数据建立索引是一个值得权衡的选择。另一个优点是，我可以删除整个数据库文件以删除一天的数据量（这是我的应用程序的常用操作）。

我可能还必须监视每个文件的表大小看看什么时候速度会成为问题。

不幸的是，除了自动真空之外，似乎没有其他增量真空方法。我无法使用它，因为我的清理目标是对文件进行碎片整理（文件空间没什么大不了的），而自动清理不会这样做。实际上，文档表明它可能使碎片变得更糟，因此我不得不定期对文件进行完全清理。

#2 楼

我们正在平台上使用50 GB +的DBS。没有抱怨效果很好。
请确保您所做的一切正确！您是否在使用预定义语句？
* SQLITE 3.7.3


事务
预制语句

应用这些设置（在创建数据库之后）
/>

PRAGMA main.page_size = 4096;
PRAGMA main.cache_size=10000;
PRAGMA main.locking_mode=EXCLUSIVE;
PRAGMA main.synchronous=NORMAL;
PRAGMA main.journal_mode=WAL;
PRAGMA main.cache_size=5000;

希望对其他人有帮助，在这里效果很好

#3 楼

我创建了最大3.5GB的SQLite数据库，没有明显的性能问题。如果我没记错的话，我认为SQLite2可能有一些下限，但我认为SQLite3没有任何此类问题。

根据“ SQLite限制”页面，每个数据库页面的最大大小为32K。数据库中的最大页面数为1024 ^ 3。因此，根据我的数学计算，最大大小为32 TB。我认为您在达到SQLite之前会达到文件系统的限制！

#4 楼

进行插入花费了48个小时以上的大部分原因是由于您的索引。更快地实现以下操作：

1-删除所有索引
2-全部插入
3-再次创建索引

#5 楼

除了通常的建议：


批量插入的索引。
大事务中的批量插入/更新。
调整缓冲区缓存/禁用日志/ w PRAGMA。
使用64位计算机（以便能够使用大量缓存™）。
[2014年7月添加]使用公用表表达式（CTE）而不是运行多个SQL查询！需要SQLite版本3.8.3。

我从使用SQLite3的经验中学到了以下内容：


为了获得最大插入速度，请不要将架构与任何列约束一起使用。 （稍后根据需要更改表，您无法使用ALTER TABLE添加约束）。
优化架构以存储所需的内容。有时，这意味着在插入数据库之前分解表和/或什至压缩/转换数据。一个很好的例子是将IP地址存储为（长）整数。
每个db文件一个表-最大限度地减少锁争用。 （如果要有一个连接对象，请使用ATTACH DATABASE。
SQLite可以在同一列中存储不同类型的数据（动态类型），利用它可以发挥自己的优势。

问题/欢迎评论。;-)

#6 楼

我有一个7GB的SQLite数据库。
使用内部连接执行特定查询需要2.6s
为了加快速度，我尝试添加索引。根据我添加的索引，有时查询下降到0.1s，有时上升到7s。
我认为我的问题是，如果列高度重复，则添加索引会降低性能：(

#7 楼

我认为有关sqlite缩放的主要抱怨是：


单进程写入。
没有镜像。
没有复制。

#8 楼

在SQLite文档中曾经有一个声明，即数据库文件的实际大小限制为几十GB：s。这主要是由于SQLite在启动事务时需要“分配脏页的位图”。因此，数据库中的每个MB都需要256字节的RAM。插入到50 GB的DB文件中将需要大量（2 ^ 8）*（2 ^ 10）= 2 ^ 18 = 256 MB的RAM。

从SQLite的最新版本开始，不再需要。在此处了解更多信息。

#9 楼

使用vacuum命令时，大型sqlite文件遇到了问题。

我还没有尝试过auto_vacuum功能。如果您希望经常更新和删除数据，那么值得一看。