问SQLITE FTS3查询比标准选项卡慢

EN

documentation解释说：

可以使用两种不同形式的SELECT语句高效地查询

FTS表：

按行by的

• 查询。如果SELECT语句的WHERE子句包含"rowid = ?“形式的子句，则where？是一个SQL表达式，则FTS能够使用相当于SQLite整数主键SQL查询的等价物直接检索请求的行。如果SELECT语句的WHERE子句包含“MATCH ?”形式的子句，则FTS能够使用内置全文索引将搜索限制在与指定为match子句右操作数的全文查询字符串匹配的那些文档。

如果这两种查询策略都不能使用，则对FTS表的所有查询都使用整个表的线性扫描来实现。

为了实现高效的查询，您应该使用

SELECT * FROM data WHERE codes MATCH 'RH12'

但这将查找包含搜索字符串的所有记录。

要有效地执行“普通”查询，您必须在普通表中保留数据的副本。(如果您想节省空间，可以使用contentless or external content表。)

您应该更仔细地阅读documentation。

使用WHERE col = 'value'对虚拟FTS表的任何查询都会很慢(除了对ROWID的查询)，但使用WHERE col MATCH 'value'的查询将使用FTS和fast。

我不是这方面的专家，但这里有一些需要考虑的事情。你的测试有缺陷(我认为)。您正在将文本完全匹配(索引可以在original_data上使用-没有什么比这个场景更好)与fts3表上的相等(我不确定FTS3是否会在这种类型的查询中起作用)的场景进行对比。如果您想要进行比较(以了解FTS3的好处)，您将需要比较original_data上的"like“操作和数据上的FTS3 "match”操作。