学习SQL Server全文索引(转)
在一个产品介绍网站中查询产品时，由于产品的介绍性文字可能会很长，如果使用对产品介绍字段使用like进行模糊查询，性能肯定会是问题。那么如何解决这个问题呢？第一个想法就是使用全文索引。那么全文索引是什么、应该如何应用、在应用的过程中又应该注意哪些事情呢？这个POST作为学习全文检索的笔记。
1、是什么
[摘录自SQL Server2000联机从书]
全文索引为在字符串数据中进行复杂的词搜索提供有效支持。全文索引存储关于重要词和这些词在特定列中的位置的信息。全文查询利用这些信息，可快速搜索包含具体某个词或一组词的行。
全文索引包含在全文目录中。每个数据库可以包含一个或多个全文目录。一个目录不能属于多个数据库，而每个目录可以包含一个或多个表的全文索引。一个表只能有一个全文索引，因此每个有全文索引的表只属于一个全文目录。
全文目录和索引不存储在它们所属的数据库中。目录和索引由 Microsoft 搜索服务分开管理。
全文索引必须在基表上定义，而不能在视图、系统表或临时表上定义。
依据上面的描述，可以做这样一个比喻。大家大概都见过档案柜，档案柜是将各种档案按照分类登记在档案索引卡上，这个档案柜中的就象建立的全文索引，通过这些档案索引卡可以迅速定位你要查找的卷宗所在的位置。如果不建立这些索引卡，如果卷宗数量不多还好，一旦档案数量很多的时候显然很难找到期望的卷宗，这就类似使用LIKE的情形。
全文索引和普通索引的区别：
| 普通SQL 索引 | 全文索引 |
| 存储时受定义它们所在的数据库的控制 | 存储在文件系统中，但通过数据库管理 |
| 每个表允许有若干个普通索引 | 每个表只允许有一个全文索引 |
| 当对作为其基础的数据进行插入、更新或删除时，它们会自动更新 | 将数据添加到全文索引称为填充，全文索引可通过调度或特定请求来请求，也可以在添加新数据时自动发生 |
| 不分组 | 在同一个数据库内分组为一个或多个全文目录 |
| 使用SQL Server企业管理器、向导或Transact-SQL语句创建和除去 | 使用SQL Server企业管理器、向导或存储过程创建、管理和除去 |
2、怎么用
例子：参见使用SQL Server2000的全文索引服务
上面这篇文章已经说的比较清楚了，这里只是把典型的几种SQL列出：
（详细描述可以在SQL Server2000联机从书中查询contains）
返回包含字符串 "sea" 或 "bread" 的所有分类描述。
Use Northwind
Select * from categories
where contains( description, ' "sea*" or "bread*" ')
（详细描述可以在SQL Server2000联机从书中查询freetext）
搜索产品描述中含有与 bread、candy、dry 和 meat 相关的词语的所有产品类别，如 breads、candies、dried 和 meats 等。
USE Northwind
GO
SELECT CategoryName
FROM Categories
WHERE FREETEXT (Description, 'sweetest candy bread and dry meat' )
GO
3、建议
a、仔细考虑维护全文索引的方式
[摘录自SQL Server2000联机从书]
维护全文索引有三种方式：
- 完全重建
重新扫描所有行。彻底重建全文索引。既可以立即执行完全重建，也可以通过 SQL Server 代理按调度进行。
- 基于时间戳的增量重建
重新扫描那些从上一次完全重建或增量重建以来曾更改过的行。这样做需要在表上有一 timestamp 列。不更新时间戳的更改（如 WRITETEXT 和 UPDATETEXT）是检测不到的。可以立即执行增量重建，也可以按调度进行。
- 更改跟踪
维护一份对索引数据的全部更改的列表。用 WRITETEXT 和 UPDATETEXT 进行的更改是检测不到的。可以用这些更改立即更新全文索引，也可以按调度进行，或者使用后台更新索引选项在更改一发生时便更新。
所使用的方法取决于许多因素，如 CPU 和可用的内存、数据更改的数量和速度、可用磁盘空间的大小，以及当前全文索引的重要性等。以下建议可作为选择维护方式时的参考。
- 当 CPU 和内存不成问题，最新索引的值很高，且即时传播可以跟得上更改的速度时，使用带后台更新索引选项的更改跟踪。
- 当 CPU 和内存可以在调度时间使用，用于存储更改的磁盘空间足够大，且调度时间之间的变化并没有大到使传播所需的时间比完全重建更长时，使用带调度传播的更改跟踪。
- 如果大部分记录的更改或添加是立即发生的，应该使用完全重建。如果大部分记录是在扩展的时间段更改的，考虑使用带调度或后台更新索引的更改跟踪。
- 如果每一次更改的文档数目很多（并不是所占的百分比很高），可以使用增量重建。如果大量记录的更改是在扩展时间段发生的，考虑使用带调度或后台更新索引的更改跟踪。
不过即使选择好作业类型后，也应该给调度全文索引的时机进行恰当的规划。由于表中数据的改变会影响全文索引内容，所以频繁的更新数据的表不太适合进行全文索引。同时可以把调度填充全文索引的时间放在系统比较空闲的时候，而且应该考虑到进行填充可能的时间。比如你可以把填充的时间定在每天晚上0:00，这个时候应该相对空闲一些（这个想法有些想当然的嫌疑
，不过一般情况下应该差不多吧）。
另外应该模拟客户处可能的数据量做个填充实验，以便对填充索引的时间长度有所估计。
啊~~全文检索所涉及的面实在是太广了。先整理这些吧~！
关于索引速度慢的问题，如果返回的结果集很大的话，建议采用分页获取，不要一次性将所有的结果返回
在Microsoft SQL Server 7.0 中提供了全文索引服务(Full-Text Search Service)，在
查询性能上，对varchar,char,text类型的字段的匹配查询比用Sql 语句使用Like操作符及匹
配符的速度快10倍以上；在查询匹配上，提供了模糊匹配的高级搜索性能并能够返回查询的命
中率。 Full Text Search Service包含在Sql Server 7.0中，在Sql Server 7 Destop版中
不起作用。安装Sql server时，无法缺省安装它，需要在Custom Installation 中选择。 服
务安装完后在Sql Server EnterPrise Manager中的Support Services中显示为Full-text
Search,在控制面版中的服务中显示为Microsoft Search.可以在Sql Server EnterPrise
Manager中启动这个服务，就可以在表中加入全文索引了。 要注意：只有有唯一索引栏的表
才能建立全文索引，并且全文索引建立好之后就不能改变表了，如要改变表就必须得取出索引
对表设置全文索引应用如下步骤： 1.选择要建立全文索引的表，然后选择： Full-Text Index Table ->Define Full-Text Indexing on a table
2.系统会启动Sql Server Full-Text Index 向导。
3.选择一个唯一索引。
4.选择一个要建立索引的字段。
5.选择catalog.
6.选择更新索引计划（由于全文索引和普通索引表不同，不能自动更新，所以得加入一个
7.Finish
8.选择在数据库Full-text catalogs中里的新建立的catalog，然后运行Start
Population,Full Population 就可以了。
大家都知道LIKE查询很慢，全文索引就是事先做好相关的索引，表示哪个主题词可以在哪些记录里找到，甚至事先计算好RANK，检索时可以把相关度高的先列出来，这可以大大提高检索的速度。
打个比方，你有很多的小抽屉，每个抽屉里面放一些杂物，假如你要找东西，最原始的方法就是一个个抽屉翻，这就是没有索引的情况。
假如聪明一点，给抽屉编号(唯一键)，把哪个号码的抽屉有什么东西记录在纸上，找东西先看看这张纸，这就是普通索引，假如你要知道哪个抽屉有什么，你可以在纸上迅速找到抽屉号码(大家知道这是使用查找树)，然后得到相关的信息，这种情况普通索引是很快的；但是要找到一个特定的东西哪些抽屉有，你就要把整张纸遍历一次，这就是LIKE查询，假如你要找哪些抽屉同时有2种甚至更多种物品，LIKE就更加繁琐了。假如一个表有上千万的纪录，大家可以想象查询的代价。
可以换一个思路，另外找张纸，记录一样东西存在于哪些抽屉：
夹子:1,3,4,5,6,9,12...
钱币:2,3,4,7,12...
药丸:1,3,5,6...
这样找到某样东西或者某几样东西都很容易。
