2

我一直在开发一个性能关键型应用程序，其中一个涉及的查询具有这种结构（名称已更改，但没有其他内容）：

SELECT x.* FROM a
LEFT OUTER JOIN (
    SELECT c_a, c_b, c_c
    FROM b
    UNION ALL
    SELECT c_a, c_b, c_c
    FROM c
) AS x
ON a.c_a = x.c_a
WHERE a.c_d = ?
ORDER BY a.c_a

我已经运行EXPLAIN QUERY PLAN了这个查询，所有索引似乎都被适当地使用了。使用命令行客户端，此查询在大约 0.75 秒内完成。考虑到数据库中的数据量，这是我所期望的。

但是，通过 SQLite 库执行的相同查询给出了截然不同的行为。Profiler 数据显示，对于该查询的一次执行，该sqlite3_step()函数花费的时间约为 120 秒。这个亚秒级的查询在库中需要两分钟，我完全没有解释为什么。

在这两种情况下操作的数据库文件是逐字节相同的。

SQLite 库是 3.7.2 版本，命令行客户端是 3.7.13 版本。我不知道这是否是一个因素，但对我来说似乎不太可能。

我尝试过的事情：

  • 清空数据库。性能没有统计学上显着的改善。
  • 改变日记模式。由于与这个问题无关的原因，我从使用回滚日志切换到 WAL，但这也确实对性能产生了任何统计上的显着影响。
4

2 回答 2

1

为了给观察者和参与者提供封闭性，升级到 SQLite 3.7.13 似乎已经解决了这个问题；现在花费了 1.5 秒，sqlite3_step()这显然是一个巨大的进步。3.7.2 似乎有一些错误或缺少优化，从而夸大了执行查询所需的时间。

其他奇怪行为的实例还包括 60 秒的倍数的延迟。这可能表明 3.7.2 中与锁相关的错误（参见EthanB 的回答）已经解决。

于 2012-08-22T18:51:48.163 回答
0

当 SQLite 库尝试运行时，命令行客户端是否锁定了数据库？我似乎记得 60 秒是 SQLite 查询超时（我使用 NHibernate 客户端遇到的）。

于 2012-08-22T17:44:00.830 回答