具有相关性的全文搜索 - 为什么需要多列索引？答案

【问题标题】：Fulltext search with relevance - why the need for a multiple columns index?具有相关性的全文搜索 - 为什么需要多列索引？
【发布时间】：2013-05-23 09:10:52
【问题描述】：

我必须在多列中实现全文搜索，并根据某些列/字段的相关性进行结果加权。

我遇到的所有解决方案似乎都使用单列索引来计算相关性，并使用一个多列索引来计算WHERE 子句。请参阅：https://stackoverflow.com/a/600915/168719 或 https://stackoverflow.com/a/6305108/168719

这是我的查询：

SELECT MATCH(name) AGAINST (text) as relevance_name, 
MATCH(description) AGAINST(text) as relevance_description, 
MATCH(description_long) AGAINST (text) as relevance_description_long 
FROM products WHERE

而我正面临以下选择：

MATCH(name, description, description_long) AGAINST (text) > 0

MATCH(name) AGAINST (text) > 0 
OR MATCH(description) AGAINST (text) > 0 
OR MATCH(description_long) AGAINST (text) > 0

排序子句之后。

ORDER BY (relevance_name * 2 + 
relevance_description * 3 + 
relevance_description_long * 4) / 9

问题是 - a（显然是首选方法）相对于 b 的优势是什么？

a 需要创建另一个全文索引（跨所有可搜索列），这显然会占用更多磁盘空间。

有什么优势？是性能问题吗？还是搜索质量？

【问题讨论】：

标签： mysql sql search full-text-search

【解决方案1】：

12.9.1. Natural Language Full-Text Searches 页上的手册告诉我们：

对于表中的每一行，MATCH() 返回一个相关值；也就是说，搜索字符串与 MATCH() 列表中命名的列中该行中的文本之间的相似性度量。

因此，MATCH () 将返回 MATCH (c1,c2,c3) 和 MATCH(c1) + MATCH(c2) + MATCH(c3) 的不同值。与 OR 运算符一起使用 match 时也会有类似的区别。

相关性是根据行中的单词数、该行中唯一单词的数量、集合中的总单词数以及包含特定单词的文档（行）数来计算的。

您应该使用方法 B，因为它与您的查询形式相同。

【讨论】：

在WHERE 子句中，我不关心确切的相关性是什么。除了筛选出不匹配的结果外，它没有其他目的。我的印象是 b 也足够了。但是为什么 a 最常被推荐呢？当然，这背后肯定有一些原因
@Konrad。对于 Match(1,2,3)，只有一次读取索引，而对于 B 则有 3 次读取，因此速度较慢。我的回答是，您应该在 select 和 where 子句中使用相同的构造。
所以你的意思是这 3 次读取（在 SELECT 中）无论如何都会被缓存，因此在方法 b 中我最终总共有 3 次读取（但不是 6 次）？在此查询中使用 a 时会添加第 4 次读取？
我说的是个人陈述。当您使用 Select M(1),M(2),M(3) [...] Where M(1) or M(2) or M(3) 时，您将获得 3 次全文索引读取。当您使用Select M(1),M(2),M(3) [...] Where M(1,2,3) 时，您有 3 次读取全文索引用于 Select 加上 1 次读取用于 Where 子句。但是在Select M(1,2,3) [...] Where M(1,2,3) 中只会读取 1 次全文索引。 Chaching 是另一回事。