performance - SQLITE 运算符 "="与 "< AND >"性能差异比较

Question

我的 sql 查询性能有一个奇怪的问题。当我使用运算符 = 在 LEFT JOIN 查询中大约需要 30.514 分钟秒，但在 的情况下< 和 > 仅需 1.717 秒。这是查询:

-- data_filehash.size>4095 AND data_filehash.size<4097  || 1.717 seconds
SELECT files.*, data_filehash.* 
FROM v_filesp AS files 
LEFT JOIN data_filehash ON files.id = data_filehash.file AND data_filehash.size>4095 AND data_filehash.size<4097  
WHERE data_filehash.file IS NULL

-- data_filehash.size=4096 || 30.515 minutes
SELECT files.*, data_filehash.* 
FROM v_filesp AS files
LEFT JOIN data_filehash ON files.id = data_filehash.file AND data_filehash.size=4096  
WHERE data_filehash.file IS NULL

结果总是相同的(我的数据库中有 33016 条记录)；
v_filep 是一个 View ；我有关于 data_filehash.size、data_filehash.file 的索引和 files(v_filesp).id 的主键；

我认为这不正常。也许我应该配置一些东西，或者我不明白。

两个查询都有 EXPLAIN QUERY PLAN:

查询 = (慢点)

SEARCH TABLE files USING INDEX files_c_dup (c_dup=?)
SEARCH TABLE dirs USING INTEGER PRIMARY KEY (rowid=?)
SEARCH TABLE data_filehash USING INDEX index_size (size=?)

查询 < 和 > (快点)

SEARCH TABLE files USING INDEX files_c_dup (c_dup=?)
SEARCH TABLE dirs USING INTEGER PRIMARY KEY (rowid=?)
SEARCH TABLE data_filehash USING INDEX index_file (file=?)

最后的步骤不同，但这意味着什么？我如何告诉数据库它应该在第一个查询中使用第二个更好的算法？

Answer 1

更新，起初我误认为不等式比较要慢得多。这通常是人们所期望的。事实并非如此，所以让我们再试一次。

通过不等式比较引擎首先必须找到所有匹配条件大小> 4095的记录，很可能会有很多。可能有很多匹配项，以至于引擎使用索引是徒劳的。可能会发生全表扫描。

但是 sqlite 在查询中只能对每个表使用一个索引。如果它不能使用大小索引，最好的办法是使用文件索引。这种空比较可能会消除大量行，从而加快查询速度。

使用相等比较要简单得多，因此它看起来使用 size 字段上的索引，但这可能比其他索引为空时消除的行数要少得多。

如果这仍然不能解释问题，您能否更新您的问题以显示返回的记录数、file=4096 的记录数和 null names 的数量.