对于我正在创建的网站，我需要搜索文章，产品以及ForumThread和ForumPosts表格等几个表格。我现在对这些表title列VARCHAR(255)中的每一个都有一个非常简单的LIKE搜索查询。标题列也被编入索引。
将来我想查看Description字段VARCHAR(Max)，我猜这会有很多记录时会非常慢。
现在我遇到了全文搜索，并对此提出了以下问题：
正如你所看到的，我完全没有这方面的经验，甚至在阅读理论之后，我仍然对它的真实含义感到困惑。
我希望有人可以给我一点指导，
感谢您的时间。
亲切的问候， 标记
答案 0 :(得分：2)
基于LIKE的查询存在的一个大问题是它们几乎肯定无法使用普通索引。因此，在描述列上添加索引以帮助提高性能对您没有任何好处。全文查询由两部分组成： 1) 更改您的查询以使用（例如）CONTAINS（）关键字而不是LIKE和 2) 创建一种不同类型的索引，使用这些关键字的查询将能够利用。
这就是事情：不仅仅是字段的大小决定了全文是否会产生重大影响。它也是行数。你可能有一个简单的nvarchar（100），它只能保留一个短的短语，但如果你必须搜索数百万行，全文仍然可以更快地搜索。关键是“必须搜索”部分 - 如果你有其他过滤器可以显着限制工作集，你的LIKE查询可能仍然可以。另一个场景是nvarchar（max）字段，只有几十行，但每个记录都有一个小说的文本。在这种情况下，您仍然希望使用全文索引。
全文搜索还有两个重要注意事项。一个是他们倾向于占用磁盘空间。这对大多数数据库来说并不是非常重要，但值得一提。另一个是他们经常需要手动重新计算，这样一篇文章就没有准备好在它被添加到数据库的那一刻进行搜索。
答案 1 :(得分：1)
在全文搜索和简单LIKE搜索之间的替代方案是为您提供更好的性能，一些加权能力以及简化搜索多个表，是构建您自己的关键字索引，例如：创建一个表：
keyword count tableid columnid rowid
------- ----- ------- -------- -----
varchar int int int int
您当然需要触发器或某种服务来保持最新状态，但您最终得到的是对所有相关关键字的计数及其出现位置的轻量级交叉引用。然后，您的搜索查询只需要查找此索引中的关键字。
这仅适用于关键字，因此，如果您想让人们搜索短语，则无法使用。你还必须结合逻辑来处理复数和无关词之类的事情。另一方面，它非常快。如果性能成为LIKE搜索的问题，并且您需要的不仅仅是关键字搜索，那么全文搜索可能是最好的方法。
答案 2 :(得分：0)
全文搜索真正适用于您的应用程序需要对BIG文本块进行密集搜索而不是用于存储名称，描述等的简单文本字段。
例如我用它来快速搜索书籍/简历的内容 - 它实际上创建了存储的所有内容的逐字索引，如果你不使用它可能会有点过分大量的文字。
您可以进行的一项设计更改是使用nVarchar（Max）而不是Varchar - 这使您能够处理Unicode文本（来自大多数已知的人字母系统），并且应该足够大以满足您的需求，如上所述。