什么是全文搜索与喜欢

我刚读了一篇关于 SQL 中“全文搜索”的文章。

我只是想知道 FTS 和 LIKE 有什么区别。我确实读了几篇文章，但找不到任何能够很好地解释它的东西。

86320 次浏览
小开

FTS 包括在一个文本字段中对单个单词进行索引，以便快速搜索许多记录。使用 LIKE 仍然需要在字段内执行字符串搜索(线性搜索或类似的搜索)。

小开

Like 只使用通配符，并没有那么强大。

全文允许更复杂的搜索，包括 And，Or，Not，甚至类似的搜索结果(SOUNDEX)和更多的条目。

我将开始查看 SQL CONTAINS () FREETEXT ()和相关的全文搜索项，以帮助更好地了解可用的内容。

小开
最佳答案

一般来说，在“准确性”和“召回”之间存在权衡。高精度意味着更少的不相关结果被呈现(没有假阳性) ，而高召回意味着更少的相关结果丢失(没有假阴性)。使用 LIKE 操作符可以提供100% 的精确性，而且不需要回收优惠。全文搜索工具为您提供了很大的灵活性，可以调低精度，以便更好地回忆。

大多数全文搜索实现使用“反向索引”。这是一个索引，其中键是单个术语，关联的值是包含术语的一组记录。全文搜索被优化以计算这些记录集的交集、并集等，并且通常提供一个排序算法来量化给定记录与搜索关键字的匹配程度。

SQLLike 操作符的效率可能极其低下。如果将其应用于未索引的列，则将使用完整扫描来查找匹配项(就像对未索引字段的任何查询一样)。如果对列进行了索引，则可以对索引键执行匹配，但效率远低于大多数索引查找。在最坏的情况下，LIKE 模式将具有需要检查每个索引键的前导通配符。相比之下，许多信息检索系统可以通过预编译选定字段中的后缀树来支持前置通配符。

全文搜索的其他典型特性包括

  • 词法分析或标记破坏 将非结构化文本块转换为 单个的单词、短语和 特殊代币
  • 形态学 分析，或阻止崩溃的变化 将一个给定的单词转换成一个索引词; 例如，治疗“老鼠”和 “鼠标”，或“电气化”和 “电”和“电”是同一个词
  • 测量 匹配记录与 查询字符串
小开

FTS 更加高效，功能更加强大(特别是对于文字破解器和堵塞功能) ... 但是请检查您的需求，因为有时候 DBs 不支持所有语言，例如 MSSQL 不支持希腊语(请查看本页 http://msdn.microsoft.com/en-us/library/ms176076(v=sql.110).aspx)

小开

真正的区别在于扫描方法。对于全文搜索，使用单词(术语)作为散列键——每个散列键都与键(术语)出现在的文档数组相关联。事情是这样的:

Document sets = {d1, d2, d3, d4, ... dn}
Term sets = {t1, t2, t3, .. tn}

现在，术语-文件矩阵(文件的哪个术语成员)可以表示为:

t1 -> {d1, d5, d9,.. dn}
t2 -> {d11, d50, d2,.. dn}
t3 -> {d23, d67, d34,.. dn}
:
tn -> {d90, d87, d57,.. dn}

当请求要求“获取包含单词/术语 t1的所有文档”时，返回文档集 {d1, d5, d9,.. dn}。

你可以破解一个非规范化的表模式来存储文档—— MySQL 表中的每一行都被认为是“文档”，一个 TEXT 列可以包含一个段落等等。反向索引将包含作为散列键的术语和作为文档 ID 的行 ID。

请记住，这个 SQL 查询将具有或多或少的 O (1)性能

  1. TEXT 栏中的单词/术语数
  2. 匹配条件的行/文档数
  3. 词/词的长度

例如，可以激发这个 SQL 来提取与给定单词 XYZ 匹配的所有行:

SELECT *
FROM   my_table
WHERE  MATCH (my_text_column) against ('XYZ' IN boolean mode) ;

警告: 如果向此查询添加 ORDERBY，则运行时将根据几个参数而有所不同，其中一个参数是匹配的行/文档的数量。所以要小心。

而 LIKE 却一无所获。它被迫线性扫描句子/字符串并找到所有匹配的术语。添加通配符会增加混乱。正如你可以想象的那样，它对于较小长度的字符串非常有效，但是对于较长的句子却会很糟糕地失败。而且绝对没有可比性，当有一个段落或一整页的文本等。


提交答案