我有一个简单的查询,比如
SELECT * FROM "mytable" where col1="foo"
在大约 0.5 秒内解析(一个 700 MB 数据库文件的大约 100'000 行的大约 100 个结果)
但是,一旦我添加 ORDER BY
就需要 120 秒。
SELECT * FROM "mytable" where col1="foo" ORDER BY col2
即使我这样限制结果
SELECT * FROM (SELECT * FROM "mytable" where col1="foo" LIMIT 1) ORDER BY col2
虽然实际上没有什么可排序的,但它需要 120 秒。
唯一的异常(exception)是如果我使用 ORDER BY rowid
(而不是 ORDER BY col2
)排序,或者当我这样做时(0.5 秒):
SELECT * FROM "mytable" WHERE rowid IN (SELECT rowid FROM "mytable" WHERE col1="foo") ORDER BY col2
我 VACUUM
对数据库进行了检查,并检查了数据库的完整性(正常),但此问题仍然存在。
我使用的是 SQLite 版本:3.7.7.1,在 phpLITEadmin 和我的 PHP 代码中都出现了减速。
编辑
EXPLAIN QUERY PLAN SELECT * FROM "mytable" WHERE col1="foo"
selectid|order|from|detail 0| 0| 0|SCAN TABLE mytable (~11345 rows)
EXPLAIN QUERY PLAN SELECT * FROM "mytable" WHERE col1="foo" ORDER BY col2
selectid|order|from|detail 0| 0| 0|SEARCH TABLE mytable USING AUTOMATIC COVERING INDEX (col1=?) (~7 rows) 0| 0| 0|USE TEMP B-TREE FOR ORDER BY
最佳答案
因此 SQLite 似乎错误地认为构建一个临时索引 ( automatic covering index ) 来运行查询而不是在内存中排序会更便宜。显然,为每个查询在 100,000 行上构建索引并不是最佳的查询计划。
一个明显的解决方案是在要执行查询/排序的列上添加索引。
CREATE INDEX col1_idx ON mytable (col1);
CREATE INDEX col2_idx ON mytable (col2);
关于database - SQLITE 使用 ORDER BY 时速度极慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/50776017/