SQLITE 3.7.13 和 3.8.0 之间的性能差异

Posted 2023-04-14

【中文标题】SQLITE 3.7.13 和 3.8.0 之间的性能差异

【英文标题】：Performance difference between SQLITE 3.7.13 and 3.8.0

【发布时间】：2014-02-12 11:06:23

【问题描述】：

更改 SQLITE 版本会对我们的查询产生巨大的性能影响。我们观察到某些查询的加速超过 25，但同时我们观察到其他查询的速度最多下降 2。 什么可能导致这种性能差异？

比较执行时间时，只有执行环境发生变化。相同的硬件，相同的数据库，相同的查询。 SQLITE 正在通过 Perl DBI 使用。

查询1的运行时间：

 SQLITE 3.8.0(Fedora 19):
 real   0m0.674s
 user   0m0.650s
 sys    0m0.021s

 SQLITE 3.7.13(Debian Wheezy):
 real   0m17.242s
 user   0m17.169s
 sys    0m0.028s

查询 2 的运行时间：

 SQLITE 3.8.0(Fedora 19):
 real   0m0.303s
 user   0m0.284s
 sys    0m0.017s


 SQLITE 3.7.13(Debian Wheezy):
 real   0m0.168s
 user   0m0.160s
 sys    0m0.007s

不确定它是否有用，但是一些用于调整数据库的参数：

 PRAGMA synchronous = OFF
 PRAGMA journal_mode = OFF
 PRAGMA locking_mode = EXCLUSIVE
 PRAGMA temp_store = MEMORY
 PRAGMA PAGE_SIZE = 4096
 PRAGMA cache_size = 125000

【问题讨论】：

这是next generation query planner。

@CL。您能否将您的评论作为答案，以便我接受？

感谢@CL.的帮助，我去了下一代查询计划器页面，其中提到低质量索引是“表中有超过 10 或 20 行的索引相同的价值”。我有一个包含重复外键的表的索引。删除索引解决了这个问题。现在两者都运行大约 0.5 秒。

我懒得provide context for the link。但是您自己的评论将适合作为答案。

【参考方案1】：

感谢@CL. 的帮助，我去了next generation query planner 页面，其中提到低质量索引是“表中有超过10 或20 行具有相同值的索引”。我有一个只包含重复外键的表的索引。删除索引解决了这个问题。