具有非常大的数据库文件的sqlite的性能特点是什么？
我知道，sqlite在超大型数据库文件中表现不佳，即使它们被支持（曾经有人对sqlite网站发表评论，指出如果你需要大于1GB的文件大小，你可能要考虑使用企业rdbms。再也找不到了，可能与旧版本的sqlite有关）。
然而，为了我的目的，我想在考虑其他解决方案之前了解它的真实性有多糟糕。
我正在谈论2GB以上的多吉字节范围内的sqlite数据文件。 有人对此有经验吗？ 任何提示/想法？
所以我用sqlite对非常大的文件做了一些测试，并得出了一些结论（至少对于我的具体应用）。
测试涉及一个带有单个表或多个表的单个sqlite文件。 每个表格大约有8列，几乎所有的整数和4个指数。
这个想法是插入足够的数据，直到sqlite文件大约50GB。
单桌
我试图用多个表将多行插入到一个sqlite文件中。 当文件大约7GB（抱歉，我不能具体说明行数）插入时间太长。 我估计我的测试插入我所有的数据需要24小时左右，但即使在48小时后也没有完成。
这导致我得出结论：单个非常大的sqlite表会存在插入问题，可能还有其他操作。
我想这并不奇怪，随着表格变大，插入和更新所有的索引需要更长的时间。
多个表
然后，我尝试将数据按时间分成多个表格，每天一个表格。 原始1表格的数据被分成〜700个表格。
这种设置在插入时没有问题，随着时间的推移它不需要更长的时间，因为每天都创建一个新表。
真空问题
正如i_like_caffeine指出的，VACUUM命令是一个问题，sqlite文件越大。 随着更多插入/删除操作的完成，磁盘上文件的碎片将变得更糟，因此目标是定期进行VACUUM以优化文件并恢复文件空间。
然而，正如文件所指出的那样，数据库的完整副本被用来完成真空，需要很长时间才能完成。 所以，数据库越小，这个操作就会结束得越快。
结论
对于我的具体应用，我可能会将数据分成几个db文件，每天一个，以获得最佳的真空性能和插入/删除速度。
这使查询变得复杂，但对我来说，能够索引这么多数据是值得的权衡。 另外一个好处是我可以删除整个数据库文件来删除一天的数据（这是我的应用程序的一个常见操作）。
我可能必须监视每个文件的表大小以及速度将成为问题的时间。
这真是太糟糕了，除了汽车真空之外，似乎没有增量真空方法。 我无法使用它，因为我的真空目标是对文件进行碎片整理（文件空间不是什么大问题），而真空吸尘器不能做到这一点。 事实上，文档指出它可能会导致分裂更糟糕，所以我不得不求助于对文件进行全面的真空处理。
我们在我们的平台上使用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.5GB大小的SQLite数据库，没有明显的性能问题。 如果我没有记错，我认为SQLite2可能有一些下限，但我不认为SQLite3有任何这样的问题。
根据SQLite限制页面，每个数据库页面的最大大小是32K。 数据库中的最大页面数为1024 ^ 3。 所以我的数学计算出来的最大尺寸是32TB。 我认为在命中SQLite之前你会达到文件系统的限制！
链接地址: http://www.djcxy.com/p/3327.html上一篇: What are the performance characteristics of sqlite with very large database files?