SQLite:实际限制是什么？

Question

在您将此问题标记为重复之前，请听我说完!!
我已经阅读了此处提出的有关如何提高性能的问题，例如仅举几例Improve INSERT-per-second performance of SQLite?和 What are the performance characteristics of sqlite with very large database files?

我正在努力让 sqlite 与 5 GB 的数据库文件一起工作。相反，有些人声称即使数据库大小高达 160 GB，sqlite 对他们也“非常好”。我自己没有尝试过，但从提出的问题来看，我猜想所有的基准测试可能只用数据库中的表完成。

我正在使用数据库
- 20张左右的 table
- 一半的表格有超过 15 列
- 这 15 个左右的列表中的每一个都有 6/7 个外键列 - 其中一些表在一个月内已经增长到拥有 2700 万条记录

我使用的开发机器是 3 GHz 四核机器，有 4 GB 内存，但仅查询这些大表中的 row_count 就需要 3 多分钟。

我找不到任何水平分区数据的方法。我最好的办法是将数据拆分到多个数据库文件中，每个表一个。但在那种情况下，据我所知，不能使用外键列约束，所以我将不得不创建一个自给自足的表(没有任何外键)。

所以我的问题是
a) 我是否为作业使用了错误的数据库？
b) 你认为我哪里出错了？
c) 我还没有在外键上添加索引，但如果仅行计数查询需要四分钟，外键索引如何帮助我？

编辑提供更多信息，即使没有人要求 :)我正在使用 SQLite 版本 3.7.9 和 system.data.sqlite.dll 版本 1.0.77.0

编辑2:我认为我与 160 名演出人员的不同之处在于他们可能会选择单个唱片或一小部分唱片。但是我必须加载表中的所有 2700 万行，将它们与另一个表连接起来，按照用户的要求对记录进行分组并返回结果。关于为此类结果优化数据库的最佳方式的任何输入。

我无法缓存先前查询的结果，因为它对我的情况没有意义。命中缓存的机会相当低。

Answer 1

这里有很多要考虑的因素，但我的第一条建议是不要只看别人的绩效统计数据。数据库性能取决于很多因素，包括数据库的结构、查询的复杂性、定义(或未定义)的索引，通常只是其中的数据量。许多报告的性能数据来自大量的试验和错误，和/或将数据库与手头的工作相匹配。换句话说，你将从任何 DBMS 获得的性能不能简单地与另一个应用程序的性能进行比较，除非你的数据集和结构几乎完全相同 - 它们当然是一个指南，也许是一个理想的争取，但您不一定会“开箱即用”地获得疯狂的性能。

作为起点，我会开始为那些非常大的表上的数据编制索引(从评论中看，您已经知道了)，然后看看会发生什么。诚然，四分钟的计数是相当长的时间，但不要停在那里。添加一些索引，改变它们，询问您是否正在存储不需要存储的数据，并查看其他数据库查询，而不仅仅是计数查询，以判断性能。 寻找其他使用 SQLite 处理大量行的应用程序和博客文章，看看他们为解决这个问题做了什么(可能包括更改数据库)。基本上，尝试一些东西——然后做出判断。不要让最初的恐惧阻止你，认为你走错了路。也许你是，也许你不是，但不要只停留在 COUNT 查询上。无论如何分割，一个表中的 2700 万条记录都是一堆废话。

最后，一个具体的建议是:在 SQLite 中，不要将数据库拆分成多个文件——我认为这没有帮助，因为那样你将不得不做很多额外的查询工作，然后在多个查询返回结果后手动连接单独的表。这是重新发明 RDBMS 为您做的事情，这是一个疯狂的想法。您不会想出比 RDBMS 系统的创建者更快的连接方法 - 您肯定会在那里浪费时间。