数据库中全文搜索与Like的差别

数据库中全文搜索与Like的差别

在SQL Server中，Like关键字可以实现模糊查询，即确定特定字符串是否与制定模式相匹配。这里的模式可以指包含常规字符和通配符。在模式匹配过程中，常规字符必须与字符串中指定的字符完全匹配。不过通过使用通配符可以改变这个规则，如使用?等通配符可以与字符串的任意部分相匹配。故Like关键字可以在数据库中实现模糊查询。

另外数据库库管理员也可以利用全文搜索功能对SQL Server数据表进行查询。在可以对给定的标进行全文查询之前，数据库管理元必须对这个数据表建立全文索引。全文索引也可以实现类似Like的模糊查询功能。如在一张人才简历表中查找符合特定字符串的信息等等。虽然说Like关键字与全文搜索在功能上大同小异，但是在实现细节上有比较大的差异。作为数据库管理员需要了解这个差异，并选择合适的实现模式。

一、查询效率上的差异。

通常情况下，Like关键字的查询效率还是比较快的。特别是对于结构化的数据，Like的查询效率、灵活性方面是值得称道的。但是对于一些非机构化的文本数据，如果通过Like 关键字来进行模糊查询的话，则其执行效率并不是很理想。特别是对于全文查询来说，其速度要慢得多。而且随着记录数量的增多，类似的差异更明显。如在一张表中，有三百万行左右的文本数据，此时如果利用Like关键字来查找相关的内容，则可能需要几分钟的时间才能够返回正确的结果。相反，对于同样的数据通过采用全文搜索功能的话，则可能只需要1分钟不到甚至更多的时间及可以返回结果。故当文本数据的行数比较多时，如在一万行以上，则此时数据库管理员若采用全文搜索功能的话，则可以比较明显的改善数据库的查询效率。

二、对空格字符的敏感性。

在数据库中如果采用Like关键字进行模糊查询，则在这个关键字后面的所有字符都有意义。如现在用户使用like “abcd ”(带有两个空格)查询时，则后面的空格字符对于Like 关键字也是敏感的。也就是说，如果用户利用上面这条语句进行查询时，则被查询的内容必须也是“abcd ”(带有两个空格)这种类型的数据才会被返回。如果被查询的内容是“abcd ”(不带空格或者带有一个空格)则数据库系统会认为这与查询条件不相符合，故不会返回相关的记录。故Like关键字对于空格是比较敏感的。为此在使用Like关键字时候需要特别注意这个问题。如果用户或者程序开发人员不能够确定abcd后面到底是否有空格，则可以通过通配符拉实现。即可以利用”%abcd%”为条件语句。如此的话，无论abcd前面或者后面是否有空格，则都会被查询出来。但是全文搜索的话，通常情况下系统会把空格忽略掉。即在全文搜索功能中，系统会先对查询条件语句进行优化。如果发现空格的话，则往往会实现把空格过滤掉。故全文搜索的话，对于空格等特殊字符往往是不敏感的。

三、对于一些特殊字符的处理要求。

由于数据类型不同，其数据存储方式也不同。为此某些特殊的数据类型可能无法通过Like关键字来实现模糊查询。如对于办好char和varchar数据的模式的字符串比较可能无法通过Like关键字来实现。也就是说，Like关键字后面带的条件语句仅对字符模式有效，不能够使用Like条件语句来查询格式化的二进制数据等等。为此如果数据库管理元要采用Like 关键字，则其必须了解每种数据类型的存储方式以及导致Like关键字比较失败的原因。知己知彼，百战百胜。只有如此数据库管理员才能够避免因为在不恰当的地方采用了Like关键字而造成查询的错误。不过值得高兴的是，Like关键字支持ASCII模式匹配与Unicode模式匹配。如果Like关键字的所有参数都为ASCII字符数据类型，则Like关键字会自动采用ASCII 模式匹配。如果其中任何一个参数为Unicode数据类型，则系统会把所有的参数都转换为Unicode数据类型，并执行Unicode模式匹配。另外需要注意的是，如果Like关键字加上Unicode的数据类型则后面条件语句的空格是有效的，即比较时会考虑到后面出现的空格。

但是如果数据类型不是Unicode的，则对后面的空格不敏感。即比较时，是否存在空格对于最后的结果不会有影响。

但是如果数据库管理员才用全文搜索的话，往往没有这方面的顾虑。因为全文搜索不仅支持传统的字符模式，而且还支持其他的数据模式。另外通过全文搜索，还可以用来查询格式化的二进制数据。为此如果在数据表中，数据模式不统一或者需要对二进制数据进行查询的话，则必这建议数据库管理员需要采用全文搜索，而不是采用Like关键字。

四、转义字符对查询的影响。

如现在在数据表中有百分制的数值。如某个序号为10的产品的不合格率为10%。此时用户可能需要找出这个合格率为10%的内容，并进行后续的操作。但是10%其中的%是一个比较特殊的字符，它是数据库中的通配符。如果利用Like ”10%”进行查询的话，则数据库会把10与10%的内容都查找出来。显然这不符合我们的需要。为了避免这种通配符等特殊字符给Like查询带来的不利影响，则需要通过Escape子句来搜索包含一个或者多个特殊通配符的字符串。如上面的例子中，要把%当作普通字符而不是通配符，就必须提供Escape 关键字和转义符号。如果Like模式中的转义符后面没有字符，则该模式无效并且LIKE 返回False。如果转义符后面的字符不是通配符，则将放弃转义符并将该转义符后面的字符作为该模式中的常规字符处理。不过在全文搜索中就不会受到这个转义字符的影响。

如现在在数据库中有abcd、ab、abef、ab*等行。现在数据库管理员希望能够查找出以ab字符开头的行，即实现前缀搜索。此时数据库管理员就可以通过’“top*”’这个条件语句来完成。此时系统就会返回所有与星号之前制定的文本相匹配的文本。如果此时数据库管理员只想查找ab*的记录，则就可以使用’top*’(不包含双引号)条件语句来完成查询需求。即如果未在文本和星号前后加上双引号的话，则全文搜索将不把星号当作通配符。这就比使用转义字符要简单的多。

五、具体应用的差异。

由于全文搜索与Like关键字在功能与性能上的一些差异，故他们在应用领域上也有所差别。SQL Server数据库在设计的时候，也是让他们各自负责一块领域。如相比Like挂泥浆案子而言，全文琐碎可能根据下面这些内容来实现特定的查询。如可以根据一个或则多个特定的词和短语来进行查询;可以通过特定词的变形来进行查询;如可以与另一个词或短语邻近的词或者短语;如可以对特定词的同义词形式来进行查询;如可以通过加权值的词或者短语来实现查询等等。正是因为全文搜索这些特异功能，决定了全文搜索在一些特定的场合中特别有用。

据了解，全文搜索在如下几个应用领域有比较突出的表现。一是在电子商务网站上，用户可以通过全文搜索功能在网站主页上根据产品规格或者名字来实现模糊查询。二是在一些人才网站上，可以通过学历、工作经验、技术特长等条件在后台数据库中查找需要的人才信息等等。不管是什么样的商业应用场景，全文搜索的基本管理任务和开发任务是相同的。不过，在给定的商业应用场景中，可以对全文索引和查询进行优化以使其满足业务目标。例如，对于电子商务来说，最大限度地提高性能可能比对结果进行排序、检索的准确性(实际上有多少个现有匹配项是由全文查询返回的)或支持多种语言更重要。对于律师事务所来说，首先需要考虑的可能是返回所有可能存在的匹配项。到目前为止，笔者参与过电子商务项目、律师案例库等几个项目中都采用了全文搜索功能，都取得了比较不错的效果。

总的来说，在一些简单查询中，使用Like关键字来实现模糊查询可能会取得比较好的效果。但是在一些比较复杂的查询应用中，特别是需要在大文本中查询相关的内容，则最好通过全文搜索来实现查询。此时后者无论在性能上、还是在准确度上都会有比较出色的表现。（