performance - 大型表上的 SQLite 性能

Question

编辑:我在这里的错误非常基本:我没有使用 PRIMARY KEY 进行索引。为了使这个线程更有用，我添加了性能数据来搜索我的表，使用和不使用索引进行性能比较。

我在 windows 和 linux 下运行的应用程序中使用 python 中的 sqlite3。我的数据库文件目前在 700 MB 范围内。

我发现一个特殊的性能问题与我最大的表中的条目数有关。它由 10 列整数和 float 以及一个 varchar 组成。

表格有 1.6 Mio 行。对于该大小，每个 SELECT 或 UPDATE 命令需要 327 毫秒。这对我的应用程序来说太长了，因为它现在主要等待 sqlite。

我认识到，性能会随着表大小的下降而显着提高。我发现:

• 160 万个条目 327 毫秒，无索引 => 29.7 毫秒，有索引
• 670k 条目 149 ms 无索引 => 28.8 ms 有索引
• 280k 条目 71 毫秒，无索引 => 28.5 毫秒，带索引
• 147k 条目 44 ms 无索引 => 28.0 ms 有索引
• 19k 条目 25 ms 无索引 => 25.0 ms 有索引

结论:使用索引搜索时间几乎保持不变，而没有索引的搜索时间几乎随着表大小线性增加。仅对于非常小的表，差异可以忽略不计。

Answer 1

当查询时间与表大小成线性关系时，您的查询可能会进行全表扫描，这意味着它们必须读取表中的所有行。这通常意味着它们不是 using indexes .

如果没有看到您的架构和查询，我们无法告诉您应该为哪些内容编制索引。您可以通过输入 EXPLAIN QUERY PLAN 来查看您的查询在做什么在它前面像 EXPLAIN QUERY PLAN SELECT * FROM foo。如果您看到“SCAN TABLE”，那就是全表扫描。如果您看到正在使用索引的“USING INDEX”。