Thanks to the help of @CL., I went to the next generation query planner page that mentioned low-quality index as being "one where there are more than 10 or 20 rows in the table that have the same value". I had one index for a table containing only repeated foreign keys. Dropping the index fixed the issue.
Performance difference between SQLITE 3.7.13 and 3.8.0
-
10-10-2022 - |
题
Changing SQLITE version has huge performance impact for our queries. We have observed a speedup of over 25 on some queries, although at the same time we observe a slow down of up to 2 on others. What could be causing this performance difference?
When comparing execution times, only the execution environment changes. Same hardware, same DB, same query. SQLITE is being used through Perl DBI.
Run time of query 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
Run time of query 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
Not sure if it is useful, but some parameters used to tune the DB:
PRAGMA synchronous = OFF
PRAGMA journal_mode = OFF
PRAGMA locking_mode = EXCLUSIVE
PRAGMA temp_store = MEMORY
PRAGMA PAGE_SIZE = 4096
PRAGMA cache_size = 125000
解决方案
不隶属于 StackOverflow