三级数据库：SQLServer全文索引不是万能的

　　下面假设有这样一个例子：在DataBase_name.dbo.Table_name中有一个名为Title(标题)和Contents(内容)的字段，现在需要查询在Title或者Contents中包括“qq”字符的所有记录。

　　面对这样的一个场景，我们通常都会写这样一个脚本：SELECT * FROM DataBase_name.dbo.Table_name WHERE Title LIKE '%qq%' OR Contents LIKE '%qq%'; 没错，这也是我第一个想到的方法。但是我们需要思考的是：随着时间的推移，数据会越来越大，那个时候我们该如何提高我们的性能?用户随时都有可能再添加对Remark(备注)字段进行查找，难道我们就应该不厌其烦地修改程序代码?

　　需要指出的是：面对这样的查询条件，即使Title和Contents上都有索引，我们也无法使用到索引，因为在 '%qq%'的“qq”前面使用了通配符，所以无法使用到索引;如果查询的条件是'qq%'，那到是可以利用上索引。在许多数据库性能调优的文章上都说OR这个谓词可以使用SELECT UNION ALL SELECT这样的方式来提高性能，但是需要提醒大家的是：如果在一条记录中字段Title和Contents都同时存在“中国”字符的话，那么返回的结果就会出现两条相同的记录，如果你希望是唯一的记录，那么这个时候你就要注意了。

　　现在回到我们上面的问题，大概这个时候大家都应该想到了数据库的全文索引了。全文索引是一种特殊类型的基于标记的功能性索引，由 Microsoft SQL Server 全文引擎 (MSFTESQL) 服务创建和维护。创建全文索引的过程与创建其他类型的索引的过程差别很大。MSFTESQL 不是基于某一特定行中存储的值来构造 B 树结构，而是基于要索引的文本中的各个标记来创建倒排、堆积且压缩的索引结构。(摘自MSDN)

　　为什么说SQL Server 全文索引不是万能的?可能大家都怀疑我是不是标题党了，呵呵，马上就讲到，那就是这个全文索引能解决我们一开始提到的场景吗?回答是否定。为什么呢?因为它的分词和倒排索引造成了对字符串“tqq.tencent.com”这样的内容进行‘“*qq*”’这样的条件查询，上面那条记录是不会被返回的。它的分词应该是正向最大值的分词方法，它没有对方向再进行一次分词和索引，索引无法查询到。这个可能会被大家所忽略掉的。