然而，为了我的目的，我想知道在我考虑其他解决方案之前它是多么糟糕。
测试涉及具有单个表或多个表的单个sqlite文件。每个表有大约8列，几乎所有的整数，和4个索引。
单表
我试图插入多个行到一个只有一个表的sqlite文件。当文件是大约7GB(对不起，我不能具体的行计数)插入花费太长时间。我估计我的插入我的所有数据的测试将需要24小时左右，但即使在48小时后也没有完成。
这使我得出结论，单个，非常大的sqlite表将有插入问题，以及可能的其他操作。
我猜这不奇怪，随着表变大，插入和更新所有的索引需要更长的时间。
多个表
然后我尝试按时间分割数据在几个表，每天一个表。原始1表的数据被分割为〜700表。
这个设置没有插入问题，它不需要更长的时间进展，因为一个新的表创建每一天。
真空问题
正如i_like_caffeine指出的，VACUUM命令是一个问题，sqlite文件越大。随着更多的插入/删除完成，磁盘上文件的碎片将变得更糟，所以目标是定期VACUUM优化文件和恢复文件空间。
然而，正如documentation所指出的，数据库的完整副本是做一个真空，需要很长时间才能完成。所以，数据库越小，这个操作就越快完成。
结论
对于我的具体应用，我可能会拆分出几个数据库文件，每天一个，以获得最好的真空性能和插入/删除速度。
这使查询复杂化，但对我来说，这是一个值得折衷的能够索引这么多的数据。另一个优点是，我可以删除整个数据库文件来删除一天的数据(我的应用程序的常见操作)。
我可能需要监视每个文件的表大小以及看到速度会成为一个问题。
这太糟糕了，似乎没有一个增量真空方法除了auto vacuum.我不能使用它，因为我的真空的目标是碎片整理文件(文件空间不是一个大事情)，自动真空不做。事实上，文档声明它可能使碎片更糟，所以我不得不诉诸于定期对文件完全真空。
