SQLite：大表上的 COUNT 慢

Question

我在 SQLite 中遇到性能问题，在大型表上使用 SELECT COUNT(*)。

由于我还没有收到可用的答案并且我做了一些进一步的测试，我编辑了我的问题以纳入我的新发现。

我有 2 张桌子：

CREATE TABLE Table1 (
Key INTEGER NOT NULL,
... several other fields ...,
Status CHAR(1) NOT NULL,
Selection VARCHAR NULL,
CONSTRAINT PK_Table1 PRIMARY KEY (Key ASC))

CREATE Table2 (
Key INTEGER NOT NULL,
Key2 INTEGER NOT NULL,
... a few other fields ...,
CONSTRAINT PK_Table2 PRIMARY KEY (Key ASC, Key2 ASC))

Table1 大约有 800 万条记录，Table2 大约有 5100 万条记录，数据库文件超过 5GB。

Table1 还有 2 个索引：

CREATE INDEX IDX_Table1_Status ON Table1 (Status ASC, Key ASC)
CREATE INDEX IDX_Table1_Selection ON Table1 (Selection ASC, Key ASC)

“状态”是必填字段，但只有 6 个不同的值，“选择”不是必需的，只有大约 150 万个与 null 不同的值，只有大约 60 万个不同的值。

我对这两个表都做了一些测试，您可以在下面看到时间安排，并且我为每个请求 (QP) 添加了“解释查询计划”。我将数据库文件放在 USB 记忆棒上，这样我就可以在每次测试后将其删除并获得可靠的结果，而不会干扰磁盘缓存。有些请求在 USB 上更快（我想是因为缺少搜索时间），但有些请求较慢（表扫描）。

SELECT COUNT(*) FROM Table1
    Time: 105 sec
    QP: SCAN TABLE Table1 USING COVERING INDEX IDX_Table1_Selection(~1000000 rows)
SELECT COUNT(Key) FROM Table1
    Time: 153 sec
    QP: SCAN TABLE Table1 (~1000000 rows)
SELECT * FROM Table1 WHERE Key = 5123456
    Time: 5 ms
    QP: SEARCH TABLE Table1 USING INTEGER PRIMARY KEY (rowid=?) (~1 rows)
SELECT * FROM Table1 WHERE Status = 73 AND Key > 5123456 LIMIT 1
    Time: 16 sec
    QP: SEARCH TABLE Table1 USING INDEX IDX_Table1_Status (Status=?) (~3 rows)
SELECT * FROM Table1 WHERE Selection = 'SomeValue' AND Key > 5123456 LIMIT 1
    Time: 9 ms
    QP: SEARCH TABLE Table1 USING INDEX IDX_Table1_Selection (Selection=?) (~3 rows)

如您所见，计数非常慢，但正常选择速度很快（第二次选择除外，需要 16 秒）。

Table2 也是如此：

SELECT COUNT(*) FROM Table2
    Time: 528 sec
    QP: SCAN TABLE Table2 USING COVERING INDEX sqlite_autoindex_Table2_1(~1000000 rows)
SELECT COUNT(Key) FROM Table2
    Time: 249 sec
    QP: SCAN TABLE Table2 (~1000000 rows)
SELECT * FROM Table2 WHERE Key = 5123456 AND Key2 = 0
    Time: 7 ms
    QP: SEARCH TABLE Table2 USING INDEX sqlite_autoindex_Table2_1 (Key=? AND Key2=?) (~1 rows)

为什么 SQLite 没有在 Table1 的主键上使用自动创建的索引？ 为什么，当他在 Table2 上使用自动索引时，仍然需要很多时间？

我在 SQL Server 2008 R2 上创建了具有相同内容和索引的相同表，并且计数几乎是瞬时的。

下面的其中一个 cmets 建议对数据库执行 ANALYZE。我做到了，花了 11 分钟才完成。 之后，我又进行了一些测试：

SELECT COUNT(*) FROM Table1
    Time: 104 sec
    QP: SCAN TABLE Table1 USING COVERING INDEX IDX_Table1_Selection(~7848023 rows)
SELECT COUNT(Key) FROM Table1
    Time: 151 sec
    QP: SCAN TABLE Table1 (~7848023 rows)
SELECT * FROM Table1 WHERE Status = 73 AND Key > 5123456 LIMIT 1
    Time: 5 ms
    QP: SEARCH TABLE Table1 USING INTEGER PRIMARY KEY (rowid>?) (~196200 rows)
SELECT COUNT(*) FROM Table2
    Time: 529 sec
    QP: SCAN TABLE Table2 USING COVERING INDEX sqlite_autoindex_Table2_1(~51152542 rows)
SELECT COUNT(Key) FROM Table2
    Time: 249 sec
    QP: SCAN TABLE Table2 (~51152542 rows)

如您所见，查询花费了相同的时间（除了查询计划现在显示实际行数），只是较慢的选择现在也很快。

接下来，我在 Table1 的 Key 字段上创建一个额外的索引，它应该对应于自动索引。我在原始数据库上做了这个，没有分析数据。创建此索引花费了 23 多分钟（请记住，这是在 USB 记忆棒上）。

CREATE INDEX IDX_Table1_Key ON Table1 (Key ASC)

然后我再次运行测试：

SELECT COUNT(*) FROM Table1
    Time: 4 sec
    QP: SCAN TABLE Table1 USING COVERING INDEX IDX_Table1_Key(~1000000 rows)
SELECT COUNT(Key) FROM Table1
    Time: 167 sec
    QP: SCAN TABLE Table2 (~1000000 rows)
SELECT * FROM Table1 WHERE Status = 73 AND Key > 5123456 LIMIT 1
    Time: 17 sec
    QP: SEARCH TABLE Table1 USING INDEX IDX_Table1_Status (Status=?) (~3 rows)

如您所见，索引对 count(*) 有帮助，但对 count(Key) 没有帮助。

最后，我使用列约束而不是表约束来创建表：

CREATE TABLE Table1 (
Key INTEGER PRIMARY KEY ASC NOT NULL,
... several other fields ...,
Status CHAR(1) NOT NULL,
Selection VARCHAR NULL)

然后我再次运行测试：

SELECT COUNT(*) FROM Table1
    Time: 6 sec
    QP: SCAN TABLE Table1 USING COVERING INDEX IDX_Table1_Selection(~1000000 rows)
SELECT COUNT(Key) FROM Table1
    Time: 28 sec
    QP: SCAN TABLE Table1 (~1000000 rows)
SELECT * FROM Table1 WHERE Status = 73 AND Key > 5123456 LIMIT 1
    Time: 10 sec
    QP: SEARCH TABLE Table1 USING INDEX IDX_Table1_Status (Status=?) (~3 rows)

虽然查询计划相同，但时间要好很多。这是为什么呢？

问题是 ALTER TABLE 不允许转换现有表，并且我有很多现有数据库无法转换为这种形式。此外，使用列约束代替表约束不适用于 Table2。

有谁知道我做错了什么以及如何解决这个问题？

我使用 System.Data.SQLite 版本 1.0.74.0 创建表并运行我使用 SQLiteSpy 1.9.1 的测试。

谢谢，

马克

Answer 1

如果您还没有DELETEd 任何记录，请执行以下操作：

SELECT MAX(_ROWID_) FROM "table" LIMIT 1;

将避免全表扫描。

注意_ROWID_ is a SQLite identifier。

Answer 2

来自http://old.nabble.com/count(*)-slow-td869876.html

SQLite 总是对 count(*) 进行全表扫描。它 不会在表上保留元信息以加快速度 处理。

不保留元信息是经过深思熟虑的设计 决定。如果每个表都存储一个计数（或者更好的是，每个 B树的节点存储了一个计数）然后更多更新 必须在每个 INSERT 或 DELETE 上发生。这 会减慢 INSERT 和 DELETE，即使在常见的情况下 count(*) 速度不重要的情况。

如果你真的需要一个快速的 COUNT，那么你可以创建 更新正在运行的 INSERT 和 DELETE 触发器 在单独的表中计数，然后查询该单独的表 表来查找最新计数。

当然，如果您保留完整的行数，则不值得 需要依赖于 WHERE 子句的 COUNT（即 WHERE field1 > 0 和 field2

Answer 3

这可能没有多大帮助，但您可以运行ANALYZE 命令来重建有关您的数据库的统计信息。尝试运行“ANALYZE;”以重建有关整个数据库的统计信息，然后再次运行查询，看看它是否更快。

Answer 4

不要数星星，数记录！或者用其他语言，永远不要发出

从表名中选择计数（*）；

使用

SELECT COUNT(ROWID) FROM 表名；

调用 EXPLAIN QUERY PLAN 以查看差异。确保您有一个包含 WHERE 子句中提到的所有列的索引。

Answer 5

关于列约束，SQLite 将声明为 INTEGER PRIMARY KEY 的列映射到内部行 id（这反过来又允许一些内部优化）。理论上，它可以对单独声明的主键约束做同样的事情，但在实践中似乎不会这样做，至少在使用 SQLite 的版本时是这样。 （System.Data.SQLite 1.0.74.0 对应于核心 SQLite 3.7.7.1。您可能想尝试使用 1.0.79.0 重新检查您的数字；您不需要更改数据库即可，只需更改库即可。）

Answer 6

快速查询的输出均以文本“QP: SEARCH”开头。而那些慢查询以文本“QP: SCAN”开头，这表明 sqlite 正在执行整个表的扫描以生成计数。

谷歌搜索“sqlite table scan count”会找到the following，这表明使用全表扫描来检索计数正是 sqlite 的工作方式，因此可能是不可避免的。

作为一种解决方法，鉴于状态只有八个值，我想知道您是否可以使用如下查询快速获得计数？

选择 1，其中状态=1 联盟 选择 1 其中状态 = 2 ...

然后计算结果中的行数。这显然很难看，但如果它说服 sqlite 将查询作为搜索而不是扫描运行，它可能会起作用。每次返回“1”的想法是避免返回真实数据的开销。

Answer 7

这是提高查询性能的潜在解决方法。从上下文来看，您的查询听起来需要大约一分半钟才能运行。

假设您有一个 date_created 列（或可以添加一个），每天午夜（例如上午 00:05）在后台运行一个查询，并将该值与计算的 last_updated 日期一起保存在某处（我会过会儿再说）。

然后，针对您的 date_created 列（带有索引）运行，您可以通过执行 SELECT COUNT(*) FROM TABLE WHERE date_updated > "[TODAY] 00:00:05" 之类的查询来避免全表扫描。

将该查询中的计数值添加到您的持久值中，您就有了一个相当快的计数，通常是准确的。

唯一的问题是，从上午 12:05 到上午 12:07（总计数查询运行的持续时间），您有一个竞争条件，您可以检查全表扫描 count() 的 last_updated 值。如果它超过 24 小时，那么您的增量计数查询需要提取一整天的计数加上今天经过的时间。如果它小于 24 小时，那么您的增量计数查询需要提取部分天数（只是今天过去的时间）。

Answer 8

我遇到了同样的问题，在我的情况下 VACUUM 命令有帮助。在数据库 COUNT(*) 上执行后，速度提高了近 100 倍。但是，命令本身在我的数据库中需要几分钟（2000 万条记录）。当我的软件在主窗口销毁后退出时，我通过运行 VACUUM 解决了这个问题，因此延迟不会给用户带来问题。