在一个产品介绍网站中查询产品时，由于产品的介绍性文字可能会很长，如果使用对产品介绍字段使用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，这个时候应该相对空闲一些（这个想法有些想当然的嫌疑
，不过一般情况下应该差不多吧）。
另外应该模拟客户处可能的数据量做个填充实验，以便对填充索引的时间长度有所估计。
啊~~全文检索所涉及的面实在是太广了。先整理这些吧~！