数据库->属性->文件-> 使用全文索引 这一选项为什么是灰色的，勾选不了
我已经启动了SQLSERVER Full Text Search 服务了，是不是需要安装其他什么东西。郁闷中，请高手解答
我的sqlserver是 标准版
13 个解决方案
#1
SQL Server 2005全文检索技术
作者：IT168 王翔 2006-10-18
1. 前言
1.1 应用背景
随着我国*和企业信息化的快速普及和发展，来自于供应链、企业生产系统、办公自动化（或公文行文）系统、人事绩效系统、财务管理系统等无一不在积累着各类数据。不仅如此，来自于企业门户网站、通过各种手持移动设备传递的会议通知、保存在业务员笔记本和PDA中的离线产品报价和短期个人销售信息也不一而足。可以说信息无处不在、无时不在、无设备不在，但是它们是否可以在您的手中，即*和企业的信息系统是否可以把员工需要的信息呈送到他们的指尖之下，这恐怕是另一回事了。信息化普遍实施后，数据获取方式、获取手段的局限，是国内信息化建设主要面临的尴尬现状。
图1：Your Data,Any Where、Any Time、Any Device. But not on your finger.
1.2 主要检索技术的区别
有了数据但是没有被使用，那么这些数据不应该被称为信息。它们无非是不断充斥设备和网络的比特而已，但是如何把数据提供给必要的人员，检索技术是其中非常有效的途径之一。本文笔者主要基于微软平台，针对SQL Server 2005提供的全文检索技术进行介绍。与关系数据查询、多维数据库查询和基于XML的XQuery、XPath不同，全文检索技术主要处理对象是基于超大数据量的文本数据和结构化的二进制数据上类似LIKE的模糊查询。主要区别见下表。
关系数据库查询 多维数据查询 XML查询 全文检索
检索技术 SQL MDX XQuery、XPath SQL (extension)
主要处理对象 关系二维数据 结构化多维数据 层次型数据 大容量二维和层次型数据的模糊检索
主要应用领域 一般的OLTP类应用 一般的OLAP类分析型应用 面向Internet、Intranet的松散耦合SOA应用 企业内部知识管理类应用
索引 大量使用非聚簇索引，一般保存在数据库中。 通过层次型、保存中间结果的方式，通过不同的轴向快速定位信息剖面。 基于XPath的索引，索引一般保存在数据库中。 基于关键字的索引，保存在文件系统中。每个表仅支持一个索引。
表1：全文检索与关系数据库查询、多维数据查询、XML查询的对比
2. 全文检索技术简要介绍
2.1 基本概念
如上文所说，全文检索主要应用领域如下：
（1）大数据量、超大数据量的结构化平文本数据和模糊匹配查找（Char、Varchar、Nvarchar）。
（2）大数据量、超大数据量的层次型XML数据展开后的查找---含模糊查找（Xml type）。
（3）标准格式的二进制非结构化Word数据的查找（VarBinary[max]、Image）。
与其他检索技术不同的是，全文检索不仅仅提供词汇层次的查询支持，而且可以根据语言环境、不同语言的特点，甚至于用户自定义的配置提供不同语义级的大容量数据模糊匹配检索支持。为了提供语义层次的检索，SQL Server 2005的全文检索明确了如下几个概念：
（1）断字符（Word Breaker）：因为对于不同的语言，哪些符号可以用于词汇的分割是不同的，因此全文检索支持不同语言环境的不同断字符。
（2）标记（Token）：是由断字符标识的词或字符串。由于划分是基于特定语言完成的，因此也可以做到语义层次的支持。
（3）干扰词（Noise Word）：主要是那些经常出现，但是对于检索没有多少帮助的词汇。例如：英语中的“a”、 “and”、 “is”、 “the”，汉语中的“的”、 “不”、 “以”、 “了”等。SQL Server 2005中提供配置文件，允许用户自定义自己语言、甚至与本行业、本企业的检索干扰词。
（4）词干分析器（Stemmer）：通过断字符分割后，根据具体的语言和该语言的语法规程生成的特定词汇的变形。
（5）同义词：即便是同一个语言，在检索的情况下也存在同义词如何处理的问题。如果一个检索系统不能够识别近义词，而只能识别完全匹配的词汇，那对于我们中文这种表义的语言而言会带来很大不便。同样的，一个行业内部也有很多同义词或者是缩略语。例如如下的词语。
广播行业 ： “ABC”与“英国ABC广播公司”基本上类似，但是也可能和“澳大利亚广播公司”混淆。
*行文： “ABC”与南美的“阿根廷、巴西、智利三国”是同义词。
军事领域： “ABC”与“原子、生物、化学战”同义。
不仅如此，由于日常使用的习惯，我们在口语表达和书面语表达上也有区别，这个也需要预先定义。例如，很多口头常用的技术产品“Win2K”、 “WinXP”等，虽然说起来很习惯，但是在行文的时候，一般都很正式的称为“Windows 2000”和 “Windows XP”，因此SQL Server 2005上也提供类似词汇替换的支持，而且这些支持也是与具体语言相关的。
2.2 SQL Server 2005全文检索的技术架构
SQL Server 2005的全文检索其实是由三个进程共同完成的，它们的总体逻辑架构如下：
图2：SQL Server 2005的总体逻辑架构
其中，三个进程分别为：
（1）SQL Server process (Sqlservr.exe)
（2）Microsoft Full-Text Engine for SQL Server process (Msftesql.exe)
（3）Microsoft Full-Text Engine Filter Daemon process (Msftefd.exe)
Msftefd主要是负责监控Msftesql进程，同时从具体的数据源根据通过使用对应的过滤器，把其中的文本信息根据断字符拆分成词汇列表（Wordlist）反馈给Msftesql进程。整个全文检索的简要执行过程如下：
（1）从客户端发送的全文查询会转到 SQL Server 进程中的 SQL Server 查询处理器 。
（2）查询处理器再将它传递给全文查询组件，该组件将创建 OLE DB 命令树，并将它发送到 Microsoft Full-Text Engine for SQL Server (MSFTESQL) 服务。
（3）在 MSFTESQL 进程中，全文引擎查询处理器将使用同义词库和干扰词文件以及断字符和词干分析器来处理查询。
（4）处理此查询之后，MSFTESQL 服务将结果集返回到 SQL Server 进程。此结果集可以用于进一步进行处理，也可以返回到客户端。
3. 规划您的全文检索
由于全文检索概念相对较多，与多数读者日常接触的关系数据库查询有所区别，因此上文笔者简单介绍了SQL Server全文检索技术的几个要点，下面笔者介绍一下面对国际化趋势，在本*或企业的分布式异构信息系统环境下，如何规划全文检索服务的建设。
3.1 全文检索服务的需求收集
抛开其他需求分析内容不谈，仅全文检索服务自身就有很多特定的需求需要明确，下面是笔者列举的一些内容。
功能性的需求：
（1）哪些业务数据需要提供全文的检索服务？
（2）这些业务数据中那些关键信息是业务人员关心的？
（3）需要支持哪些国家的语言？
（4）有哪些行业术语、常用缩略词、替换词？
（5）需要哪些检索功能，分别基于什么范畴的关键字展开检索？
非功能性的需求：
（1）业务上以前是否尝试过关系数据库查询、多维数据分析解决手头的问题？
（2）检索时效性要求。
（3）习惯的检索操作平台（浏览器 / 桌面），查询结果的展示方式。
（4）授权控制。
（5）查询结果的导出和发布方式要求。
作者：IT168 王翔 2006-10-18
1. 前言
1.1 应用背景
随着我国*和企业信息化的快速普及和发展，来自于供应链、企业生产系统、办公自动化（或公文行文）系统、人事绩效系统、财务管理系统等无一不在积累着各类数据。不仅如此，来自于企业门户网站、通过各种手持移动设备传递的会议通知、保存在业务员笔记本和PDA中的离线产品报价和短期个人销售信息也不一而足。可以说信息无处不在、无时不在、无设备不在，但是它们是否可以在您的手中，即*和企业的信息系统是否可以把员工需要的信息呈送到他们的指尖之下，这恐怕是另一回事了。信息化普遍实施后，数据获取方式、获取手段的局限，是国内信息化建设主要面临的尴尬现状。
图1：Your Data,Any Where、Any Time、Any Device. But not on your finger.
1.2 主要检索技术的区别
有了数据但是没有被使用，那么这些数据不应该被称为信息。它们无非是不断充斥设备和网络的比特而已，但是如何把数据提供给必要的人员，检索技术是其中非常有效的途径之一。本文笔者主要基于微软平台，针对SQL Server 2005提供的全文检索技术进行介绍。与关系数据查询、多维数据库查询和基于XML的XQuery、XPath不同，全文检索技术主要处理对象是基于超大数据量的文本数据和结构化的二进制数据上类似LIKE的模糊查询。主要区别见下表。
关系数据库查询 多维数据查询 XML查询 全文检索
检索技术 SQL MDX XQuery、XPath SQL (extension)
主要处理对象 关系二维数据 结构化多维数据 层次型数据 大容量二维和层次型数据的模糊检索
主要应用领域 一般的OLTP类应用 一般的OLAP类分析型应用 面向Internet、Intranet的松散耦合SOA应用 企业内部知识管理类应用
索引 大量使用非聚簇索引，一般保存在数据库中。 通过层次型、保存中间结果的方式，通过不同的轴向快速定位信息剖面。 基于XPath的索引，索引一般保存在数据库中。 基于关键字的索引，保存在文件系统中。每个表仅支持一个索引。
表1：全文检索与关系数据库查询、多维数据查询、XML查询的对比
2. 全文检索技术简要介绍
2.1 基本概念
如上文所说，全文检索主要应用领域如下：
（1）大数据量、超大数据量的结构化平文本数据和模糊匹配查找（Char、Varchar、Nvarchar）。
（2）大数据量、超大数据量的层次型XML数据展开后的查找---含模糊查找（Xml type）。
（3）标准格式的二进制非结构化Word数据的查找（VarBinary[max]、Image）。
与其他检索技术不同的是，全文检索不仅仅提供词汇层次的查询支持，而且可以根据语言环境、不同语言的特点，甚至于用户自定义的配置提供不同语义级的大容量数据模糊匹配检索支持。为了提供语义层次的检索，SQL Server 2005的全文检索明确了如下几个概念：
（1）断字符（Word Breaker）：因为对于不同的语言，哪些符号可以用于词汇的分割是不同的，因此全文检索支持不同语言环境的不同断字符。
（2）标记（Token）：是由断字符标识的词或字符串。由于划分是基于特定语言完成的，因此也可以做到语义层次的支持。
（3）干扰词（Noise Word）：主要是那些经常出现，但是对于检索没有多少帮助的词汇。例如：英语中的“a”、 “and”、 “is”、 “the”，汉语中的“的”、 “不”、 “以”、 “了”等。SQL Server 2005中提供配置文件，允许用户自定义自己语言、甚至与本行业、本企业的检索干扰词。
（4）词干分析器（Stemmer）：通过断字符分割后，根据具体的语言和该语言的语法规程生成的特定词汇的变形。
（5）同义词：即便是同一个语言，在检索的情况下也存在同义词如何处理的问题。如果一个检索系统不能够识别近义词，而只能识别完全匹配的词汇，那对于我们中文这种表义的语言而言会带来很大不便。同样的，一个行业内部也有很多同义词或者是缩略语。例如如下的词语。
广播行业 ： “ABC”与“英国ABC广播公司”基本上类似，但是也可能和“澳大利亚广播公司”混淆。
*行文： “ABC”与南美的“阿根廷、巴西、智利三国”是同义词。
军事领域： “ABC”与“原子、生物、化学战”同义。
不仅如此，由于日常使用的习惯，我们在口语表达和书面语表达上也有区别，这个也需要预先定义。例如，很多口头常用的技术产品“Win2K”、 “WinXP”等，虽然说起来很习惯，但是在行文的时候，一般都很正式的称为“Windows 2000”和 “Windows XP”，因此SQL Server 2005上也提供类似词汇替换的支持，而且这些支持也是与具体语言相关的。
2.2 SQL Server 2005全文检索的技术架构
SQL Server 2005的全文检索其实是由三个进程共同完成的，它们的总体逻辑架构如下：
图2：SQL Server 2005的总体逻辑架构
其中，三个进程分别为：
（1）SQL Server process (Sqlservr.exe)
（2）Microsoft Full-Text Engine for SQL Server process (Msftesql.exe)
（3）Microsoft Full-Text Engine Filter Daemon process (Msftefd.exe)
Msftefd主要是负责监控Msftesql进程，同时从具体的数据源根据通过使用对应的过滤器，把其中的文本信息根据断字符拆分成词汇列表（Wordlist）反馈给Msftesql进程。整个全文检索的简要执行过程如下：
（1）从客户端发送的全文查询会转到 SQL Server 进程中的 SQL Server 查询处理器 。
（2）查询处理器再将它传递给全文查询组件，该组件将创建 OLE DB 命令树，并将它发送到 Microsoft Full-Text Engine for SQL Server (MSFTESQL) 服务。
（3）在 MSFTESQL 进程中，全文引擎查询处理器将使用同义词库和干扰词文件以及断字符和词干分析器来处理查询。
（4）处理此查询之后，MSFTESQL 服务将结果集返回到 SQL Server 进程。此结果集可以用于进一步进行处理，也可以返回到客户端。
3. 规划您的全文检索
由于全文检索概念相对较多，与多数读者日常接触的关系数据库查询有所区别，因此上文笔者简单介绍了SQL Server全文检索技术的几个要点，下面笔者介绍一下面对国际化趋势，在本*或企业的分布式异构信息系统环境下，如何规划全文检索服务的建设。
3.1 全文检索服务的需求收集
抛开其他需求分析内容不谈，仅全文检索服务自身就有很多特定的需求需要明确，下面是笔者列举的一些内容。
功能性的需求：
（1）哪些业务数据需要提供全文的检索服务？
（2）这些业务数据中那些关键信息是业务人员关心的？
（3）需要支持哪些国家的语言？
（4）有哪些行业术语、常用缩略词、替换词？
（5）需要哪些检索功能，分别基于什么范畴的关键字展开检索？
非功能性的需求：
（1）业务上以前是否尝试过关系数据库查询、多维数据分析解决手头的问题？
（2）检索时效性要求。
（3）习惯的检索操作平台（浏览器 / 桌面），查询结果的展示方式。
（4）授权控制。
（5）查询结果的导出和发布方式要求。
#2
3.2 全文检索服务的需求分析
作为系统分析人员，在收集到这些信息后，需要从技术的角度考虑现有的技术储备是否可以完成业务的要求，根据上面的业务需求，下面是笔者认为需要考虑的技术要点：
（1）是否真的有必要使用全文检索技术，以往的关系数据库查询、多维数据分析、XML数据检索是否可以满足上述功能。
（2）用户要求的数据是否分布在不同的系统中，是否分布在不同的数据库上。
（3）数据源是否位于异构的操作系统和数据库上。
（4）不同语言的信息如何存储呢，拆分到不同的表，还是在应用层合并。还是直接通过跨语言的同义词解决不同语言之上的关键词查找。
（5）如何选择现成的产品来集成，并完成操作台开发、信息发布、查询结果导出。
（6）通过数据库授权、证书系统授权还是应用自定义授权解决访问的安全性。
3.3 数据源的规划
SQL Server 2005可以同时支持如下三种数据：
（1）Char、Varchar、Nvarchar
（2）XML
（3）VarBinary（max）、Image
对于第一种，由于都是SQL Server的内置类型，因此数据提取很容易。对于后两种，为了保证Word、Excel、Power Point之类的格式化二进制数据可以被检索，一般在规划上还要增加伪列来标明对应的文件扩展名。这样，可以保证SQL Server 2005全文检索的过滤器可以从对应的文件中提取出需要的文本内容，并把它通过断字符拆分成有效的词汇列表（Wordlist）。集成方式如下：
图3：标准VarBinary(max)、Image、XML类型的集成方式
通过查询视图sys.fulltext_document_types可以获得已经安装的过滤器（即支持的文档类型），下面是现有SQL Server 2005默认支持的文档类型：
（1）.ascx、.asm、.asp、.aspx、.bat、.c、
（2）.cmd、.cpp、.cxx、.def、.dic、.doc、
（3）.dot、.h、.hhc、.hpp、.htm、.html、
（4）.htw、.htx、.hxx、.ibq、.idl、.inc、
（5）.inf、.ini、.inx、.js、.log、.m3u、.mht、
（6）.obd、.obt、.odc、.pl、.pot、.ppt、.rc、
（7）.reg、.rtf、.stm、.txt、.url、.vbs、.wtx、
（8）.xlb、.xlc、.xls、.xlt、.xml
对于远程的SQL Server， 可以通过链接服务器方式访问远端数据源的全文检索系统。若要对链接服务器执行全文查询，必须先对远程服务器上的目标表和列创建全文索引。然后，将远程服务器添加为链接服务器。完成这些操作后，可以在包括CONTAINS 或 FREETEXT 这些全文查询的语句中使用，不过检索对象的命名是由四部分组成的名称对链接服务器上的目标表和列进行查询。
此外，对于以往保存在Oracle、DB2、MySQL等数据库产品上的text、image数据，也可以通过SQL Server的复制或者集成服务来进行数据同步。这个同步要根据文本内容的更新频率、业务许可间隔、数据类型进行配置。常用的同步方式如下：
（1）通过SQL Job，基于 ODBC/OLEDB 的分布式查询定期更新。该方式可以视为从SQL Server端，定期批量从异构数据库“拉”出数据。
（2）通过IIOP、HTTP、Trigger + JOB、External Server等方式向SQL Server写入。该方式可以视为异构数据库根据配置定期向SQL Server端写入，即向SQL Server “推”数据。
（3）复制：该方式可以提供更为实时的同步，即可以通过具有事务性（Transactional）的单票数据更新实现，也属于向SQL Server “推”数据。
（4）通过中间介质 Export / Import：通过平文本之类的中间介质，配合FTP、Queue等发送方式，完成异构数据库的导出和SQL Server端的异步入库。
图4：异构数据库与SQL Server的同步方式
另外，对于大型的*行业和企业而言，还存在多数据中心间的全文检索数据源同步的问题。对于这种远程的系统，异构数据源的导入要本着就近原则，全文检索上需要考虑尽量在集中的某个中心上执行。
图5：多数据中心的全文检索部署体系
说明如下：每个中心内部的异构数据源的导入在本数据中心内部完成；不同数据中心间通过双向的Linked Server完成；但是对于每个点视为其他中心对自己的单向Linked Server；客户端全文检索在就近的SQL Server 2005服务器上执行。
3.4 引入*行业或者企业自身的的数据字典
为了让SQL Server 2005的全文检索更适于本*行业或者企业使用，还需要把自己特色的缩略语、书面替换语进行配置。但是，在此之前，还要把主要使用的语言的相关信息进行配置，主要是配置相关的断字符和干扰字。
SQL Server 2005的断字符配置是根据语言分析规则而异，可以为每个全文索引列指定不同的语言。每种语言的断字符能够使得为该语言生成的词更加准确。如果断字符用于整个语系而不是特定的子语言，将使用该语系中的主要语言。例如，使用法语断字符来处理加拿大法语文本。如果某一特定语言没有可用的断字符，将使用非特定语言断字符。使用非特定语言断字符时，词将在非特定语言字符（如空格和标点符号）处断开。
SQL Server 2005 包含 23 种区域设置的断字符。通过参阅 sys.fulltext_languages 就可以获得所有支持语言的列表。
地区编号 语言
2052 Simplified Chinese
1028 Traditional Chinese
1031 German
2057 British English
1033 English
3082 Spanish
1036 French
1040 Italian
1041 Japanese
1042 Korean
0 Neutral
1043 Dutch
1053 Swedish
1054 Thai
3076 Chinese (Hong Kong SAR, PRC)
5124 Chinese (Macau SAR)
4100 Chinese (Singapore)
表2：SQL Server 2005支持的23种区域语言
注：所查询的全文索引列的语言决定了对 CONTAINS、FREETEXT、CONTAINSTABLE 和 FREETEXTTABLE 等全文查询函数的参数执行的语言分析。如果未指定列的语言，默认值是配置选项 default full-text language 的值。对于SQL Server 2005的本地版本，SQL Server 安装程序将把 default full-text language 选项设置为操作系统使用的语言；对于 SQL Server 的非本地化版本，default full-text language 选项为“英语”。
在明确了区域语言之后，还需要进行本*行业或者企业的定制化操作：
（1）在$<SQL Server Install Path>\Microsoft SQL Server\MSSQL.1\MSSQL\FTDATA\中配置对应的干扰词，可以在对应的noise***.文件中增加或者修改干扰词。
例如，对以一家IT公司而言，查询的时候就直接说服务器的名字，而把 “服务器”作为干扰词，查询某个网站的时候也就直接称呼网站的名字，把“网站”也可以作为干扰词。
（2）更为重要的是配置自己的同义词和替换词，同样在$<SQL Server Install Path>\Microsoft SQL Server\MSSQL.1\MSSQL\FTDATA\中配置对应区域语言的ts***.xml文件即可。
例如，把tsCHS.xml修改为如下内容：
<?xml version="1.0" encoding="utf-8"?>
<XML ID="Microsoft Search Thesaurus">
<thesaurus xmlns="x-schema:tsSchema.xml">
<diacritics_sensitive>0</diacritics_sensitive>
<expansion>
<sub>Internet Explorer</sub>
<sub>IE</sub>
<sub>IE5</sub>
</expansion>
<replacement>
<pat>NT5</pat>
<pat>W2K</pat>
<sub>Windows 2000</sub>
</replacement>
<expansion>
<sub>北京站</sub>
<sub>北京火车站</sub>
<sub>北京东站</sub>
</expansion>
</thesaurus>
</XML>
对于同义词在检索的时候，如果用户的查询关键字是“北京站”，那么记录内容为“北京火车站”和“北京东站”的信息也会被查询出来；对于替换词，如果用户查找的是“NT5”或“W2K”的时候，只有包括“Windows 2000”的内容会被提取出来，而 包括“NT5”或“W2K”自身的内容反而不会被提取出来。
4. 设计全文检索的统一视图
4.1设计统一的全文检索结果Schema
如果要实现统一的检索视图，第一步要从后端统一检索结果的Schema。笔者这里设计一个简易的Schema，另外预留一个扩展字段，作为各种信息的扩展需要。设计上该扩展字段最好设计为XML类型，因为一方面它是可以进一步扩展的，另一方面它也是结构良好的，可以通过Xpath的索引快速查询。Schema如下：
图6：一个统一的查询结果Schema
说明如下。
URL：定义信息的来源。
Title：定义检索到的信息的Title（文章标题、数据信息的说明内容）。
DocumentType：定义检索结果的文档类型。
Content：定义包括关键字的一个相关的句子内容。
InventoryDate：定义该检索内容的入库登记时间。
Extension：扩展信息。
例如，如果您的全文检索系统是面向采购的，那么这个Extensionn您可以用来保存联系人的各种信息。设计上首先可以定义该字段的XSD，然后通过这个XSD对输入的数据进行验证，下面是笔者给出的一个示例XSD和示例Extension内容。
作为系统分析人员，在收集到这些信息后，需要从技术的角度考虑现有的技术储备是否可以完成业务的要求，根据上面的业务需求，下面是笔者认为需要考虑的技术要点：
（1）是否真的有必要使用全文检索技术，以往的关系数据库查询、多维数据分析、XML数据检索是否可以满足上述功能。
（2）用户要求的数据是否分布在不同的系统中，是否分布在不同的数据库上。
（3）数据源是否位于异构的操作系统和数据库上。
（4）不同语言的信息如何存储呢，拆分到不同的表，还是在应用层合并。还是直接通过跨语言的同义词解决不同语言之上的关键词查找。
（5）如何选择现成的产品来集成，并完成操作台开发、信息发布、查询结果导出。
（6）通过数据库授权、证书系统授权还是应用自定义授权解决访问的安全性。
3.3 数据源的规划
SQL Server 2005可以同时支持如下三种数据：
（1）Char、Varchar、Nvarchar
（2）XML
（3）VarBinary（max）、Image
对于第一种，由于都是SQL Server的内置类型，因此数据提取很容易。对于后两种，为了保证Word、Excel、Power Point之类的格式化二进制数据可以被检索，一般在规划上还要增加伪列来标明对应的文件扩展名。这样，可以保证SQL Server 2005全文检索的过滤器可以从对应的文件中提取出需要的文本内容，并把它通过断字符拆分成有效的词汇列表（Wordlist）。集成方式如下：
图3：标准VarBinary(max)、Image、XML类型的集成方式
通过查询视图sys.fulltext_document_types可以获得已经安装的过滤器（即支持的文档类型），下面是现有SQL Server 2005默认支持的文档类型：
（1）.ascx、.asm、.asp、.aspx、.bat、.c、
（2）.cmd、.cpp、.cxx、.def、.dic、.doc、
（3）.dot、.h、.hhc、.hpp、.htm、.html、
（4）.htw、.htx、.hxx、.ibq、.idl、.inc、
（5）.inf、.ini、.inx、.js、.log、.m3u、.mht、
（6）.obd、.obt、.odc、.pl、.pot、.ppt、.rc、
（7）.reg、.rtf、.stm、.txt、.url、.vbs、.wtx、
（8）.xlb、.xlc、.xls、.xlt、.xml
对于远程的SQL Server， 可以通过链接服务器方式访问远端数据源的全文检索系统。若要对链接服务器执行全文查询，必须先对远程服务器上的目标表和列创建全文索引。然后，将远程服务器添加为链接服务器。完成这些操作后，可以在包括CONTAINS 或 FREETEXT 这些全文查询的语句中使用，不过检索对象的命名是由四部分组成的名称对链接服务器上的目标表和列进行查询。
此外，对于以往保存在Oracle、DB2、MySQL等数据库产品上的text、image数据，也可以通过SQL Server的复制或者集成服务来进行数据同步。这个同步要根据文本内容的更新频率、业务许可间隔、数据类型进行配置。常用的同步方式如下：
（1）通过SQL Job，基于 ODBC/OLEDB 的分布式查询定期更新。该方式可以视为从SQL Server端，定期批量从异构数据库“拉”出数据。
（2）通过IIOP、HTTP、Trigger + JOB、External Server等方式向SQL Server写入。该方式可以视为异构数据库根据配置定期向SQL Server端写入，即向SQL Server “推”数据。
（3）复制：该方式可以提供更为实时的同步，即可以通过具有事务性（Transactional）的单票数据更新实现，也属于向SQL Server “推”数据。
（4）通过中间介质 Export / Import：通过平文本之类的中间介质，配合FTP、Queue等发送方式，完成异构数据库的导出和SQL Server端的异步入库。
图4：异构数据库与SQL Server的同步方式
另外，对于大型的*行业和企业而言，还存在多数据中心间的全文检索数据源同步的问题。对于这种远程的系统，异构数据源的导入要本着就近原则，全文检索上需要考虑尽量在集中的某个中心上执行。
图5：多数据中心的全文检索部署体系
说明如下：每个中心内部的异构数据源的导入在本数据中心内部完成；不同数据中心间通过双向的Linked Server完成；但是对于每个点视为其他中心对自己的单向Linked Server；客户端全文检索在就近的SQL Server 2005服务器上执行。
3.4 引入*行业或者企业自身的的数据字典
为了让SQL Server 2005的全文检索更适于本*行业或者企业使用，还需要把自己特色的缩略语、书面替换语进行配置。但是，在此之前，还要把主要使用的语言的相关信息进行配置，主要是配置相关的断字符和干扰字。
SQL Server 2005的断字符配置是根据语言分析规则而异，可以为每个全文索引列指定不同的语言。每种语言的断字符能够使得为该语言生成的词更加准确。如果断字符用于整个语系而不是特定的子语言，将使用该语系中的主要语言。例如，使用法语断字符来处理加拿大法语文本。如果某一特定语言没有可用的断字符，将使用非特定语言断字符。使用非特定语言断字符时，词将在非特定语言字符（如空格和标点符号）处断开。
SQL Server 2005 包含 23 种区域设置的断字符。通过参阅 sys.fulltext_languages 就可以获得所有支持语言的列表。
地区编号 语言
2052 Simplified Chinese
1028 Traditional Chinese
1031 German
2057 British English
1033 English
3082 Spanish
1036 French
1040 Italian
1041 Japanese
1042 Korean
0 Neutral
1043 Dutch
1053 Swedish
1054 Thai
3076 Chinese (Hong Kong SAR, PRC)
5124 Chinese (Macau SAR)
4100 Chinese (Singapore)
表2：SQL Server 2005支持的23种区域语言
注：所查询的全文索引列的语言决定了对 CONTAINS、FREETEXT、CONTAINSTABLE 和 FREETEXTTABLE 等全文查询函数的参数执行的语言分析。如果未指定列的语言，默认值是配置选项 default full-text language 的值。对于SQL Server 2005的本地版本，SQL Server 安装程序将把 default full-text language 选项设置为操作系统使用的语言；对于 SQL Server 的非本地化版本，default full-text language 选项为“英语”。
在明确了区域语言之后，还需要进行本*行业或者企业的定制化操作：
（1）在$<SQL Server Install Path>\Microsoft SQL Server\MSSQL.1\MSSQL\FTDATA\中配置对应的干扰词，可以在对应的noise***.文件中增加或者修改干扰词。
例如，对以一家IT公司而言，查询的时候就直接说服务器的名字，而把 “服务器”作为干扰词，查询某个网站的时候也就直接称呼网站的名字，把“网站”也可以作为干扰词。
（2）更为重要的是配置自己的同义词和替换词，同样在$<SQL Server Install Path>\Microsoft SQL Server\MSSQL.1\MSSQL\FTDATA\中配置对应区域语言的ts***.xml文件即可。
例如，把tsCHS.xml修改为如下内容：
<?xml version="1.0" encoding="utf-8"?>
<XML ID="Microsoft Search Thesaurus">
<thesaurus xmlns="x-schema:tsSchema.xml">
<diacritics_sensitive>0</diacritics_sensitive>
<expansion>
<sub>Internet Explorer</sub>
<sub>IE</sub>
<sub>IE5</sub>
</expansion>
<replacement>
<pat>NT5</pat>
<pat>W2K</pat>
<sub>Windows 2000</sub>
</replacement>
<expansion>
<sub>北京站</sub>
<sub>北京火车站</sub>
<sub>北京东站</sub>
</expansion>
</thesaurus>
</XML>
对于同义词在检索的时候，如果用户的查询关键字是“北京站”，那么记录内容为“北京火车站”和“北京东站”的信息也会被查询出来；对于替换词，如果用户查找的是“NT5”或“W2K”的时候，只有包括“Windows 2000”的内容会被提取出来，而 包括“NT5”或“W2K”自身的内容反而不会被提取出来。
4. 设计全文检索的统一视图
4.1设计统一的全文检索结果Schema
如果要实现统一的检索视图，第一步要从后端统一检索结果的Schema。笔者这里设计一个简易的Schema，另外预留一个扩展字段，作为各种信息的扩展需要。设计上该扩展字段最好设计为XML类型，因为一方面它是可以进一步扩展的，另一方面它也是结构良好的，可以通过Xpath的索引快速查询。Schema如下：
图6：一个统一的查询结果Schema
说明如下。
URL：定义信息的来源。
Title：定义检索到的信息的Title（文章标题、数据信息的说明内容）。
DocumentType：定义检索结果的文档类型。
Content：定义包括关键字的一个相关的句子内容。
InventoryDate：定义该检索内容的入库登记时间。
Extension：扩展信息。
例如，如果您的全文检索系统是面向采购的，那么这个Extensionn您可以用来保存联系人的各种信息。设计上首先可以定义该字段的XSD，然后通过这个XSD对输入的数据进行验证，下面是笔者给出的一个示例XSD和示例Extension内容。
#3
图6：联系人的示例XSD和一个示例的数据
URL Title Doc
Type
Content Inventory
Date
Extension
Http://
www.ViT.com
Full-text
Data
Definition
Language
PDF Microsoft SQL Server 2005 introduces new Transact-SQL data definition language (DDL) statements for creating, implementing, and managing full-text catalogs and indexes. The following is a list of the new Full-Text Search DDL statements.
4.2 多个全文检索结果的前期设计
受到全文检索仅仅支持单个表的限制，每个全文检索的结果相对有限。但是，对于用户而言他们常常做的是一个模糊的关键词在通盘信息中的检索，这些工作应该由开发人员在应用层通过搜索引擎帮助用户进行后台的合并。此外，对于整个*行业和大型的企业而言，非结构化文本数据和结构化二进制信息资源很可能物理上分散在不同的物理位置上。因此，对于高层的决策者和信息工作者而言，他们也需要查询引擎内部提供检索结果合并的支持。
这里，基于上文笔者提出的统一检索结果Schema，统一全文检索系统需要提供一个配置库，用于保存不同全文检索功能需要把哪些检索命令的执行结果进行合并，此外考虑到个别高级用户的需要，还需要提供给这一部分用户Ad-Hoc同时全文检索多个数据内容（甚至是多个信息源）的支持。为了说明这个数据合并的过程，这里笔者假设了一个业务应用情形：
? （1）AdventureWorks公司的高管、人事、财务等部门位于A城的总部（Headquarter），使用的是SQL Server 2005。
? （2）AdventureWorks公司的仓库位于B城，但是生产系统与总部是互联的，使用的是SQL Server 2005。
? （3）AdventureWorks公司的1号工厂位于C城，但是生产系统与总部是互联的，使用的是SQL Server 2005。
? （4）AdventureWorks公司最近收购了Northwind的工厂，作为它的2号工厂，这个工厂也位于B城，但是生产系统与AdventureWorks总部和原有的仓库也是互联的，使用的是Oracle 9i，但是产品信息很少，相关产品绝大多数都是在本地销售。
图7：示例应用的地理分布关系
那么根据各地的信息，如果要查询和“中国”相关的信息，各自相关的全文检索命令类似下表。
ID
编号 Title
检索内容 Site 位置 DB
数据库 Command
检索命令示例
Q_01 A点人事信息 A Adventureworks SELECT Comments，StartWorkDate
FROM <prefix>HR.Employee
WHERE CONTAINS(Comments, ' "from china" ');
GO
Q_02 A点财务信息 A Adventureworks SELECT Notes，AccountDate
FROM <prefix>Finance.Expanse
WHERE CONTAINS（Notes, ' " china" ');
GO
Q_03 B点仓库信息 B Adventureworks SELECT Note, RegisterDate
FROM <prefix>Warehouse.Inventory
WHERE CONTAINS(Note, ' "from china" ');
GO
Q_04 2号工厂的产品信息。
（已将Oracle的信息导入到SQL Server 2005的Northwind数据库）
B Northwind SELECT COMMENT, INPUT_DATE
FROM <prefix>PRODUCT_LIST
WHERE ORIGINAL_COUNTRY = 'CHINA'
GO
Q_05 1号工厂的产品信息 C Adventureworks SELECT Note, InputDate
FROM <prefix>Production.Producct
WHERE CONTAINS(Note, ' "from china" ');
GO
表3：查询的配置表 (Q : Query)
说明如下。
这里既有全文检索也有关系数据库查询，例如：由于Northwind由于产品信息很少，而且登记产品的时候还登记了产品的来源国，所以完全可以通过关系数据库查询完成检索工作。
? 其他全文检索的示例都采用的是本地搜索特定词或短语（简单词条）的方式。
? 与可以直接执行的语句不同，这里每个查询的FROM对象前面还有个<prefix>，它的内容会根据查询是本地还是远程链接服务器在运行态动态修改的。
如果想要高管要在A城检索全部的人事信息、财务信息、产品信息，根据上面讨论需要增加一系列统一查询结果的配置登记。
1． 链接服务器登记表
ID
编号
Name
名称 From
从 To
至 DB
数据库 Comment 检索命令示例
LS_01 LSAtoBwithAdventureworks A B Adventureworks A城SQL Server到B城SQL Server Adventureworks数据库的连接服务器
LS_02 LSAtoBwithNorthwind A B Northwind A城SQL Server到B城SQL Server Northwind数据库的连接服务器
LS_03 LSAtoCwithAdventureworks A C Adventureworks A城SQL Server到C城SQL Server Adventureworks数据库的连接服务器
LS_04 LSCtoAwithAdventureworks C A Adventureworks C城SQL Server到A城SQL Server Adventureworks数据库的连接服务器
LS_05 LSBtoAwithAdventureworks B A Adventureworks B城SQL Server到A城SQL Server Adventureworks数据库的连接服务器
表：连接服务器登记表 (LS : Linked Server)
2． 查询结果统一化登记表
这里为了所有的操作都可以配置化，同时为了提高开发库的重用性，笔者采用了XSD-〉XSLT->XSD的描述方式。
注：当然，读者也完全可以通过配置专用的转换Assembly + Class完成，只不过如果交换的全文检索内容很多的话，需要重复进行很多开发工作。
上文笔者统一化的查询结果Schema用XSD表示如下：
图8：统一化的全文检索查询结果Schema
注：用Stylus Studio XML Enterprise Edition的XML Designer显示的结果。
以查询结果Q_01为例，如果要把它统一化，那么需要在全文检索的结果中增加几个查询配置表的内容作为占位伪列（Placeholder column）。然后，与统一检索结果Schema的映射关系如下：
url ：http:// hr.adventureworks.com
title ：人事信息
documentType：DB
content：查询结果的Comments字段
inventoryDate：查询结果的StartWorkDate字段
extension：null
处理上，仅需要配置一个如下映射关系的XSLT就可以完成：
图9：把查询Q_01的结果影射为统一化查询结果Schema的XSLT
3． 业务检索登记表
ID
编号
Step
查询组成步骤
Q_ID
查询编号
Converter
转换关系
BQ_AllProduct 1 Q_04 .......
BQ_AllProduct 2 Q_05 .......
BQ_QueryHr 1 Q_01 <?xml version='1.0' ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<unifiedFullTextResult url="http://hr.adventureworks.com" title="人事信息" documentType="DB" extension="null">
<xsl:attribute name="content">
<xsl:value-of select="hrQuery/@Comment"/>
</xsl:attribute>
<xsl:attribute name="inventoryDate">
<xsl:value-of select="hrQuery/@StartWorkDate"/>
</xsl:attribute>
</unifiedFullTextResult>
</xsl:template>
</xsl:stylesheet>
URL Title Doc
Type
Content Inventory
Date
Extension
Http://
www.ViT.com
Full-text
Data
Definition
Language
PDF Microsoft SQL Server 2005 introduces new Transact-SQL data definition language (DDL) statements for creating, implementing, and managing full-text catalogs and indexes. The following is a list of the new Full-Text Search DDL statements.
4.2 多个全文检索结果的前期设计
受到全文检索仅仅支持单个表的限制，每个全文检索的结果相对有限。但是，对于用户而言他们常常做的是一个模糊的关键词在通盘信息中的检索，这些工作应该由开发人员在应用层通过搜索引擎帮助用户进行后台的合并。此外，对于整个*行业和大型的企业而言，非结构化文本数据和结构化二进制信息资源很可能物理上分散在不同的物理位置上。因此，对于高层的决策者和信息工作者而言，他们也需要查询引擎内部提供检索结果合并的支持。
这里，基于上文笔者提出的统一检索结果Schema，统一全文检索系统需要提供一个配置库，用于保存不同全文检索功能需要把哪些检索命令的执行结果进行合并，此外考虑到个别高级用户的需要，还需要提供给这一部分用户Ad-Hoc同时全文检索多个数据内容（甚至是多个信息源）的支持。为了说明这个数据合并的过程，这里笔者假设了一个业务应用情形：
? （1）AdventureWorks公司的高管、人事、财务等部门位于A城的总部（Headquarter），使用的是SQL Server 2005。
? （2）AdventureWorks公司的仓库位于B城，但是生产系统与总部是互联的，使用的是SQL Server 2005。
? （3）AdventureWorks公司的1号工厂位于C城，但是生产系统与总部是互联的，使用的是SQL Server 2005。
? （4）AdventureWorks公司最近收购了Northwind的工厂，作为它的2号工厂，这个工厂也位于B城，但是生产系统与AdventureWorks总部和原有的仓库也是互联的，使用的是Oracle 9i，但是产品信息很少，相关产品绝大多数都是在本地销售。
图7：示例应用的地理分布关系
那么根据各地的信息，如果要查询和“中国”相关的信息，各自相关的全文检索命令类似下表。
ID
编号 Title
检索内容 Site 位置 DB
数据库 Command
检索命令示例
Q_01 A点人事信息 A Adventureworks SELECT Comments，StartWorkDate
FROM <prefix>HR.Employee
WHERE CONTAINS(Comments, ' "from china" ');
GO
Q_02 A点财务信息 A Adventureworks SELECT Notes，AccountDate
FROM <prefix>Finance.Expanse
WHERE CONTAINS（Notes, ' " china" ');
GO
Q_03 B点仓库信息 B Adventureworks SELECT Note, RegisterDate
FROM <prefix>Warehouse.Inventory
WHERE CONTAINS(Note, ' "from china" ');
GO
Q_04 2号工厂的产品信息。
（已将Oracle的信息导入到SQL Server 2005的Northwind数据库）
B Northwind SELECT COMMENT, INPUT_DATE
FROM <prefix>PRODUCT_LIST
WHERE ORIGINAL_COUNTRY = 'CHINA'
GO
Q_05 1号工厂的产品信息 C Adventureworks SELECT Note, InputDate
FROM <prefix>Production.Producct
WHERE CONTAINS(Note, ' "from china" ');
GO
表3：查询的配置表 (Q : Query)
说明如下。
这里既有全文检索也有关系数据库查询，例如：由于Northwind由于产品信息很少，而且登记产品的时候还登记了产品的来源国，所以完全可以通过关系数据库查询完成检索工作。
? 其他全文检索的示例都采用的是本地搜索特定词或短语（简单词条）的方式。
? 与可以直接执行的语句不同，这里每个查询的FROM对象前面还有个<prefix>，它的内容会根据查询是本地还是远程链接服务器在运行态动态修改的。
如果想要高管要在A城检索全部的人事信息、财务信息、产品信息，根据上面讨论需要增加一系列统一查询结果的配置登记。
1． 链接服务器登记表
ID
编号
Name
名称 From
从 To
至 DB
数据库 Comment 检索命令示例
LS_01 LSAtoBwithAdventureworks A B Adventureworks A城SQL Server到B城SQL Server Adventureworks数据库的连接服务器
LS_02 LSAtoBwithNorthwind A B Northwind A城SQL Server到B城SQL Server Northwind数据库的连接服务器
LS_03 LSAtoCwithAdventureworks A C Adventureworks A城SQL Server到C城SQL Server Adventureworks数据库的连接服务器
LS_04 LSCtoAwithAdventureworks C A Adventureworks C城SQL Server到A城SQL Server Adventureworks数据库的连接服务器
LS_05 LSBtoAwithAdventureworks B A Adventureworks B城SQL Server到A城SQL Server Adventureworks数据库的连接服务器
表：连接服务器登记表 (LS : Linked Server)
2． 查询结果统一化登记表
这里为了所有的操作都可以配置化，同时为了提高开发库的重用性，笔者采用了XSD-〉XSLT->XSD的描述方式。
注：当然，读者也完全可以通过配置专用的转换Assembly + Class完成，只不过如果交换的全文检索内容很多的话，需要重复进行很多开发工作。
上文笔者统一化的查询结果Schema用XSD表示如下：
图8：统一化的全文检索查询结果Schema
注：用Stylus Studio XML Enterprise Edition的XML Designer显示的结果。
以查询结果Q_01为例，如果要把它统一化，那么需要在全文检索的结果中增加几个查询配置表的内容作为占位伪列（Placeholder column）。然后，与统一检索结果Schema的映射关系如下：
url ：http:// hr.adventureworks.com
title ：人事信息
documentType：DB
content：查询结果的Comments字段
inventoryDate：查询结果的StartWorkDate字段
extension：null
处理上，仅需要配置一个如下映射关系的XSLT就可以完成：
图9：把查询Q_01的结果影射为统一化查询结果Schema的XSLT
3． 业务检索登记表
ID
编号
Step
查询组成步骤
Q_ID
查询编号
Converter
转换关系
BQ_AllProduct 1 Q_04 .......
BQ_AllProduct 2 Q_05 .......
BQ_QueryHr 1 Q_01 <?xml version='1.0' ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<unifiedFullTextResult url="http://hr.adventureworks.com" title="人事信息" documentType="DB" extension="null">
<xsl:attribute name="content">
<xsl:value-of select="hrQuery/@Comment"/>
</xsl:attribute>
<xsl:attribute name="inventoryDate">
<xsl:value-of select="hrQuery/@StartWorkDate"/>
</xsl:attribute>
</unifiedFullTextResult>
</xsl:template>
</xsl:stylesheet>
#4
4.3 多个全文检索结果的合并
在完成了上述准备工作后，就可以在应用上设计实际的合并过程了。步骤如下：
1． 在某一城市的客户端发起了一个全文检索的业务查询请求。
2． 查询引擎根据“业务查询登记表”的内容了解如果完成这个请求，需要执行哪个几个具体查询。
3． 查询引擎带着具体查询列表，通过查询“查询的配置表”了解哪些查询是本地的、哪些查询是远程的，并且获得了模式化的查询命令。
4． 对于数据源位于本地的查询，直接在模式化查询命令上增加 USE <DB> GO子句，并且把<prefix>用空串替换，这样就获得了本地的查询命令。
5． 对于数据源位于远程的查询，还需要通过查询“链接服务器登记表”，了解这个查询需要通过哪个逻辑名称的链接服务器间接查询，并且替换模式化查询命令的USE <DB> GO和<prefix>部分。
6． 当所有的查询命令（本地 / 远程）都准备好了之后，查询引擎并发的把请求提交，并获得了一组非统一化的数据查询结果。
7． 查询引擎根据“业务查询登记表”表中每个查询结果的统一化转换配置，把每个查询结果统一化成为标准的统一Schema。
8． 最后，查询引擎把统一化的查询结果合并。
4.4 合并结果的多样化展示
虽然数据是统一化Schema的，并且内容也是合并的，但是用户UI地展示却应该是多种多样的。对于胖客户端应用，完全可以通过开发不同的User Control，绑定查询结果即可；对于浏览器客户端，更为简单，只需要配置好一个合并结果的XML -> HTML的XSLT就可以自动的把结果绑定并展示为用户需要的形式。
5. 优化SQL Server 2005的全文检索
对于一个企业级的全文检索系统，尤其是笔者上文所设计的多数据中心、异构数据源的全文检索系统，如何在运维过程不断优化系统的执行效率也是很有挑战的工作。由于全文检索过程中不仅涉及大量的IO操作，也存在执行过程中频繁的CPU计算工作，因此这里笔者提供几个关键指标，用于粗略判断系统的关键性能瓶颈。
5.1 CPU
如果由 MSFTESQL 服务和 SQL Server 所占用的 CPU 使用率接近百分之百，则 CPU 成为瓶颈。
Catalog Counter
Processor % Processor Time
% Privileged Time
System Processor Queue Length
Context Switches/sec
表5：判断CPU瓶颈的主要指标
下面对于一台单纯进行全文检索的服务器而言，是一个典型的内存瓶颈结果。
图10：CPU成为系统瓶颈
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）减少应用的并发。
（2）对于大量用户频繁访问的固定内容的全文检索，可以通过Reporting Service把结果内容固定下来，减少用户普遍关心但是结果固定的全文检索查询。
（3）通过SQL Server Cluster，借助Scale out或者Scale up分担负载。
5.2 内存
由于全文检索的过程需要在内容临时存放大量的中间结果，因此内存也很容易成为应用的瓶颈。
Catalog Counter
Memory Available MBytes
Page Reads/sec
Pages/sec
Cache Bytes
Cache Faults/sec
Server Pool Nonpaged Failures
Pool Nonpaged Peak
Cache MDL Read Hits %
表6：判断内存瓶颈的主要指标
下面对于一台单纯进行全文检索的服务器而言，是一个典型的内存瓶颈结果。
图11：内存成为系统瓶颈
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）减少应用的并发。
（2）配置SQL Job，把长时间挂起或者工作时间没有必要的过大查询的session清理。
（3）优化检索语句。
（4）尽量精确限制条件，可能的话尽量在尺寸较小的列上定义全文检索索引。
（5）适当增加内存。
（6）根据用户需要，使用TOP_<N>_BY_RANK，而不是把所有符合条件的内容全部提取。
5.3 磁盘IO
如果平均磁盘等待队列长度多于磁盘头数量的两倍，则磁盘成为瓶颈。主要的解决方法是创建独立于 SQL Server 数据库文件和日志的全文目录。将日志、数据库文件和全文目录分别放在不同的磁盘上。购买运行速度更快的磁盘和使用 RAID 也能帮助改善索引性能。
Catalog Counter
PhysicalDisk Avg. Disk Queue Length
Avg. Disk Read Queue Length
Avg. Disk Write Queue Length
Avg. Disk sec/Read
Avg. Disk sec/Transfer
Disk Writes/sec
表7：判断磁盘IO瓶颈的主要指标
5.4 网络IO
由于上文设计中，很多的采用了基于链接服务器的查询，因此网络IO也可能成为系统的瓶颈。
Catalog Counter
Network Interface Bytes Total/sec
Bytes Received/sec
Bytes Sent/sec
Server Bytes Total/sec
Protocol Protocol_Object\Segments Received/sec
Protocol_Object\Segments Sent/sec
Processor % Interrupt Time
表8：判断网络IO瓶颈的主要指标
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）采用磁盘换网络的方法，将异地数据多个节点间冗余的保存。
（2）把当前Session的多个请求打包，一次性的提交到同一远程数据库。
（3）配置SQL Job，把长时间挂起或者工作时间没有必要的过大查询的session清理。
（4）优化检索语句。
（5）尽量精确限制条件，减少反馈的数据量。
（6）根据用户需要，使用TOP_<N>_BY_RANK，而不是把所有符合条件的内容全部提取，减少反馈的数据量。
5.5 其他说明
此外，官方文档还提供了如下的建议：
（1）使用 ALTER INDEX REORGANIZE 对基表的索引进行碎片整理。
（2）使用 ALTER FULLTEXT CATALOG REORGANIZE 重新组织全文目录。请务必在性能测试之前执行此操作，因为它会导致该目录中全文索引的主合并。
（3）仅选择较小的列作为全文键列。即使支持 900 字节的列，我们也不建议您使用这么大的键列来创建全文索引。
（4）将多个 CONTAINS 谓词合并为一个 CONTAINS 谓词。在 SQL Server 中，您可以在 CONTAINS 查询中指定一个包含若干列的列表。
（5）如果只需要全文键或排名的信息，请分别使用 CONTAINSTABLE 或 FREETEXTTABLE，而不要使用 CONTAINS 或 FREETEXT。
（6）若要限制结果数并提高性能，请使用 FREETEXTTABLE 和 CONTAINSTABLE 语法的 TOP_N_BY_RANK 选项。如果您不是对可能查询到的所有信息都感兴趣，可使用此选项。
（7）检查全文查询计划以确保选择了适当的联接计划。若有必要，可使用一个联接提示或查询提示。如果全文查询中使用了参数，则该参数的第一时间值决定查询计划。可使用 OPTIMIZE FOR 查询提示来强制使用所需值编写查询。这有助于获得确定性查询和更好的性能。
6. 更多的集成选择
当然，SQL Server 2005的全文检索不是微软平台上的唯一选择，其他主要的全文检索技术如下：
（1）Index Server, Indexing Service for Microsoft Windows
（2）Microsoft SharePoint? Portal Server 2001（及后续版本）
（3）Microsoft SQL Server 7.0 、SQL Server 2000、SQL Server 2005
（4）Microsoft Exchange Server 2000（及后续版本）
（5）Microsoft Site Server 3.0
（6）Microsoft Office XP（及后续版本）
对于这些全文检索技术，笔者不准备展开介绍，只不过提醒您的是这些技术既有操作系统内置的也有需要购买服务器端产品才可以获得的，它们的检索对象领域各有不同。不过它们都具有微软平台产品普遍开发比较容易的特点，如果您要提供企业全文检索的同时，还考虑提供用户本地桌面或者是文件服务器、Web服务器内容检索的话，完全不必把它们登记到SQL Server 2005里，直接使用对应的技术通过简单的开发即可，结合笔者上文提供查询结果合并的办法一样可以快速的完成系统集成。
7. 总结
本文笔者简单介绍了SQL Server 2005的全文检索技术，及其如何应用于企业级的检索环境，文章最后还提供了其他微软平台全文检索技术的特性对别，结合关系数据库查询、多维数据分析、XML数据查询，希望您可以参照上文的合并方式真正的把本*行业或者企业内部的信息用起来，真正做到“随时、随地、任何设备上您的数据就在指尖。”
在完成了上述准备工作后，就可以在应用上设计实际的合并过程了。步骤如下：
1． 在某一城市的客户端发起了一个全文检索的业务查询请求。
2． 查询引擎根据“业务查询登记表”的内容了解如果完成这个请求，需要执行哪个几个具体查询。
3． 查询引擎带着具体查询列表，通过查询“查询的配置表”了解哪些查询是本地的、哪些查询是远程的，并且获得了模式化的查询命令。
4． 对于数据源位于本地的查询，直接在模式化查询命令上增加 USE <DB> GO子句，并且把<prefix>用空串替换，这样就获得了本地的查询命令。
5． 对于数据源位于远程的查询，还需要通过查询“链接服务器登记表”，了解这个查询需要通过哪个逻辑名称的链接服务器间接查询，并且替换模式化查询命令的USE <DB> GO和<prefix>部分。
6． 当所有的查询命令（本地 / 远程）都准备好了之后，查询引擎并发的把请求提交，并获得了一组非统一化的数据查询结果。
7． 查询引擎根据“业务查询登记表”表中每个查询结果的统一化转换配置，把每个查询结果统一化成为标准的统一Schema。
8． 最后，查询引擎把统一化的查询结果合并。
4.4 合并结果的多样化展示
虽然数据是统一化Schema的，并且内容也是合并的，但是用户UI地展示却应该是多种多样的。对于胖客户端应用，完全可以通过开发不同的User Control，绑定查询结果即可；对于浏览器客户端，更为简单，只需要配置好一个合并结果的XML -> HTML的XSLT就可以自动的把结果绑定并展示为用户需要的形式。
5. 优化SQL Server 2005的全文检索
对于一个企业级的全文检索系统，尤其是笔者上文所设计的多数据中心、异构数据源的全文检索系统，如何在运维过程不断优化系统的执行效率也是很有挑战的工作。由于全文检索过程中不仅涉及大量的IO操作，也存在执行过程中频繁的CPU计算工作，因此这里笔者提供几个关键指标，用于粗略判断系统的关键性能瓶颈。
5.1 CPU
如果由 MSFTESQL 服务和 SQL Server 所占用的 CPU 使用率接近百分之百，则 CPU 成为瓶颈。
Catalog Counter
Processor % Processor Time
% Privileged Time
System Processor Queue Length
Context Switches/sec
表5：判断CPU瓶颈的主要指标
下面对于一台单纯进行全文检索的服务器而言，是一个典型的内存瓶颈结果。
图10：CPU成为系统瓶颈
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）减少应用的并发。
（2）对于大量用户频繁访问的固定内容的全文检索，可以通过Reporting Service把结果内容固定下来，减少用户普遍关心但是结果固定的全文检索查询。
（3）通过SQL Server Cluster，借助Scale out或者Scale up分担负载。
5.2 内存
由于全文检索的过程需要在内容临时存放大量的中间结果，因此内存也很容易成为应用的瓶颈。
Catalog Counter
Memory Available MBytes
Page Reads/sec
Pages/sec
Cache Bytes
Cache Faults/sec
Server Pool Nonpaged Failures
Pool Nonpaged Peak
Cache MDL Read Hits %
表6：判断内存瓶颈的主要指标
下面对于一台单纯进行全文检索的服务器而言，是一个典型的内存瓶颈结果。
图11：内存成为系统瓶颈
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）减少应用的并发。
（2）配置SQL Job，把长时间挂起或者工作时间没有必要的过大查询的session清理。
（3）优化检索语句。
（4）尽量精确限制条件，可能的话尽量在尺寸较小的列上定义全文检索索引。
（5）适当增加内存。
（6）根据用户需要，使用TOP_<N>_BY_RANK，而不是把所有符合条件的内容全部提取。
5.3 磁盘IO
如果平均磁盘等待队列长度多于磁盘头数量的两倍，则磁盘成为瓶颈。主要的解决方法是创建独立于 SQL Server 数据库文件和日志的全文目录。将日志、数据库文件和全文目录分别放在不同的磁盘上。购买运行速度更快的磁盘和使用 RAID 也能帮助改善索引性能。
Catalog Counter
PhysicalDisk Avg. Disk Queue Length
Avg. Disk Read Queue Length
Avg. Disk Write Queue Length
Avg. Disk sec/Read
Avg. Disk sec/Transfer
Disk Writes/sec
表7：判断磁盘IO瓶颈的主要指标
5.4 网络IO
由于上文设计中，很多的采用了基于链接服务器的查询，因此网络IO也可能成为系统的瓶颈。
Catalog Counter
Network Interface Bytes Total/sec
Bytes Received/sec
Bytes Sent/sec
Server Bytes Total/sec
Protocol Protocol_Object\Segments Received/sec
Protocol_Object\Segments Sent/sec
Processor % Interrupt Time
表8：判断网络IO瓶颈的主要指标
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）采用磁盘换网络的方法，将异地数据多个节点间冗余的保存。
（2）把当前Session的多个请求打包，一次性的提交到同一远程数据库。
（3）配置SQL Job，把长时间挂起或者工作时间没有必要的过大查询的session清理。
（4）优化检索语句。
（5）尽量精确限制条件，减少反馈的数据量。
（6）根据用户需要，使用TOP_<N>_BY_RANK，而不是把所有符合条件的内容全部提取，减少反馈的数据量。
5.5 其他说明
此外，官方文档还提供了如下的建议：
（1）使用 ALTER INDEX REORGANIZE 对基表的索引进行碎片整理。
（2）使用 ALTER FULLTEXT CATALOG REORGANIZE 重新组织全文目录。请务必在性能测试之前执行此操作，因为它会导致该目录中全文索引的主合并。
（3）仅选择较小的列作为全文键列。即使支持 900 字节的列，我们也不建议您使用这么大的键列来创建全文索引。
（4）将多个 CONTAINS 谓词合并为一个 CONTAINS 谓词。在 SQL Server 中，您可以在 CONTAINS 查询中指定一个包含若干列的列表。
（5）如果只需要全文键或排名的信息，请分别使用 CONTAINSTABLE 或 FREETEXTTABLE，而不要使用 CONTAINS 或 FREETEXT。
（6）若要限制结果数并提高性能，请使用 FREETEXTTABLE 和 CONTAINSTABLE 语法的 TOP_N_BY_RANK 选项。如果您不是对可能查询到的所有信息都感兴趣，可使用此选项。
（7）检查全文查询计划以确保选择了适当的联接计划。若有必要，可使用一个联接提示或查询提示。如果全文查询中使用了参数，则该参数的第一时间值决定查询计划。可使用 OPTIMIZE FOR 查询提示来强制使用所需值编写查询。这有助于获得确定性查询和更好的性能。
6. 更多的集成选择
当然，SQL Server 2005的全文检索不是微软平台上的唯一选择，其他主要的全文检索技术如下：
（1）Index Server, Indexing Service for Microsoft Windows
（2）Microsoft SharePoint? Portal Server 2001（及后续版本）
（3）Microsoft SQL Server 7.0 、SQL Server 2000、SQL Server 2005
（4）Microsoft Exchange Server 2000（及后续版本）
（5）Microsoft Site Server 3.0
（6）Microsoft Office XP（及后续版本）
对于这些全文检索技术，笔者不准备展开介绍，只不过提醒您的是这些技术既有操作系统内置的也有需要购买服务器端产品才可以获得的，它们的检索对象领域各有不同。不过它们都具有微软平台产品普遍开发比较容易的特点，如果您要提供企业全文检索的同时，还考虑提供用户本地桌面或者是文件服务器、Web服务器内容检索的话，完全不必把它们登记到SQL Server 2005里，直接使用对应的技术通过简单的开发即可，结合笔者上文提供查询结果合并的办法一样可以快速的完成系统集成。
7. 总结
本文笔者简单介绍了SQL Server 2005的全文检索技术，及其如何应用于企业级的检索环境，文章最后还提供了其他微软平台全文检索技术的特性对别，结合关系数据库查询、多维数据分析、XML数据查询，希望您可以参照上文的合并方式真正的把本*行业或者企业内部的信息用起来，真正做到“随时、随地、任何设备上您的数据就在指尖。”
#5
数据库-> 属性-> 文件-> 使用全文索引 这一选项为什么是灰色的，勾选不了
我已经启动了SQLSERVER Full Text Search 服务了，是不是需要安装其他什么东西。郁闷中，请高手解答
我已经启动了SQLSERVER Full Text Search 服务了，是不是需要安装其他什么东西。郁闷中，请高手解答
#6
MARK
#7
#8
初学sql 跟楼主一样的问题，
#9
跟你一样的问题
那你还把分给粘贴一堆莫名其妙东西的人
#10
up
我 在 sql 2008 中也碰到了同样的问题
我 在 sql 2008 中也碰到了同样的问题
#11
我没积分~正在努力回帖中~
#12
我也遇到这个问题。到底该怎么解决啊？
#13
你要创建全文索引的数据库右键菜单--》属性--》左侧的选择页中选择"文件"--》勾选右侧的“使用全文索引”
#1
SQL Server 2005全文检索技术
作者：IT168 王翔 2006-10-18
1. 前言
1.1 应用背景
随着我国*和企业信息化的快速普及和发展，来自于供应链、企业生产系统、办公自动化（或公文行文）系统、人事绩效系统、财务管理系统等无一不在积累着各类数据。不仅如此，来自于企业门户网站、通过各种手持移动设备传递的会议通知、保存在业务员笔记本和PDA中的离线产品报价和短期个人销售信息也不一而足。可以说信息无处不在、无时不在、无设备不在，但是它们是否可以在您的手中，即*和企业的信息系统是否可以把员工需要的信息呈送到他们的指尖之下，这恐怕是另一回事了。信息化普遍实施后，数据获取方式、获取手段的局限，是国内信息化建设主要面临的尴尬现状。
图1：Your Data,Any Where、Any Time、Any Device. But not on your finger.
1.2 主要检索技术的区别
有了数据但是没有被使用，那么这些数据不应该被称为信息。它们无非是不断充斥设备和网络的比特而已，但是如何把数据提供给必要的人员，检索技术是其中非常有效的途径之一。本文笔者主要基于微软平台，针对SQL Server 2005提供的全文检索技术进行介绍。与关系数据查询、多维数据库查询和基于XML的XQuery、XPath不同，全文检索技术主要处理对象是基于超大数据量的文本数据和结构化的二进制数据上类似LIKE的模糊查询。主要区别见下表。
关系数据库查询 多维数据查询 XML查询 全文检索
检索技术 SQL MDX XQuery、XPath SQL (extension)
主要处理对象 关系二维数据 结构化多维数据 层次型数据 大容量二维和层次型数据的模糊检索
主要应用领域 一般的OLTP类应用 一般的OLAP类分析型应用 面向Internet、Intranet的松散耦合SOA应用 企业内部知识管理类应用
索引 大量使用非聚簇索引，一般保存在数据库中。 通过层次型、保存中间结果的方式，通过不同的轴向快速定位信息剖面。 基于XPath的索引，索引一般保存在数据库中。 基于关键字的索引，保存在文件系统中。每个表仅支持一个索引。
表1：全文检索与关系数据库查询、多维数据查询、XML查询的对比
2. 全文检索技术简要介绍
2.1 基本概念
如上文所说，全文检索主要应用领域如下：
（1）大数据量、超大数据量的结构化平文本数据和模糊匹配查找（Char、Varchar、Nvarchar）。
（2）大数据量、超大数据量的层次型XML数据展开后的查找---含模糊查找（Xml type）。
（3）标准格式的二进制非结构化Word数据的查找（VarBinary[max]、Image）。
与其他检索技术不同的是，全文检索不仅仅提供词汇层次的查询支持，而且可以根据语言环境、不同语言的特点，甚至于用户自定义的配置提供不同语义级的大容量数据模糊匹配检索支持。为了提供语义层次的检索，SQL Server 2005的全文检索明确了如下几个概念：
（1）断字符（Word Breaker）：因为对于不同的语言，哪些符号可以用于词汇的分割是不同的，因此全文检索支持不同语言环境的不同断字符。
（2）标记（Token）：是由断字符标识的词或字符串。由于划分是基于特定语言完成的，因此也可以做到语义层次的支持。
（3）干扰词（Noise Word）：主要是那些经常出现，但是对于检索没有多少帮助的词汇。例如：英语中的“a”、 “and”、 “is”、 “the”，汉语中的“的”、 “不”、 “以”、 “了”等。SQL Server 2005中提供配置文件，允许用户自定义自己语言、甚至与本行业、本企业的检索干扰词。
（4）词干分析器（Stemmer）：通过断字符分割后，根据具体的语言和该语言的语法规程生成的特定词汇的变形。
（5）同义词：即便是同一个语言，在检索的情况下也存在同义词如何处理的问题。如果一个检索系统不能够识别近义词，而只能识别完全匹配的词汇，那对于我们中文这种表义的语言而言会带来很大不便。同样的，一个行业内部也有很多同义词或者是缩略语。例如如下的词语。
广播行业 ： “ABC”与“英国ABC广播公司”基本上类似，但是也可能和“澳大利亚广播公司”混淆。
*行文： “ABC”与南美的“阿根廷、巴西、智利三国”是同义词。
军事领域： “ABC”与“原子、生物、化学战”同义。
不仅如此，由于日常使用的习惯，我们在口语表达和书面语表达上也有区别，这个也需要预先定义。例如，很多口头常用的技术产品“Win2K”、 “WinXP”等，虽然说起来很习惯，但是在行文的时候，一般都很正式的称为“Windows 2000”和 “Windows XP”，因此SQL Server 2005上也提供类似词汇替换的支持，而且这些支持也是与具体语言相关的。
2.2 SQL Server 2005全文检索的技术架构
SQL Server 2005的全文检索其实是由三个进程共同完成的，它们的总体逻辑架构如下：
图2：SQL Server 2005的总体逻辑架构
其中，三个进程分别为：
（1）SQL Server process (Sqlservr.exe)
（2）Microsoft Full-Text Engine for SQL Server process (Msftesql.exe)
（3）Microsoft Full-Text Engine Filter Daemon process (Msftefd.exe)
Msftefd主要是负责监控Msftesql进程，同时从具体的数据源根据通过使用对应的过滤器，把其中的文本信息根据断字符拆分成词汇列表（Wordlist）反馈给Msftesql进程。整个全文检索的简要执行过程如下：
（1）从客户端发送的全文查询会转到 SQL Server 进程中的 SQL Server 查询处理器 。
（2）查询处理器再将它传递给全文查询组件，该组件将创建 OLE DB 命令树，并将它发送到 Microsoft Full-Text Engine for SQL Server (MSFTESQL) 服务。
（3）在 MSFTESQL 进程中，全文引擎查询处理器将使用同义词库和干扰词文件以及断字符和词干分析器来处理查询。
（4）处理此查询之后，MSFTESQL 服务将结果集返回到 SQL Server 进程。此结果集可以用于进一步进行处理，也可以返回到客户端。
3. 规划您的全文检索
由于全文检索概念相对较多，与多数读者日常接触的关系数据库查询有所区别，因此上文笔者简单介绍了SQL Server全文检索技术的几个要点，下面笔者介绍一下面对国际化趋势，在本*或企业的分布式异构信息系统环境下，如何规划全文检索服务的建设。
3.1 全文检索服务的需求收集
抛开其他需求分析内容不谈，仅全文检索服务自身就有很多特定的需求需要明确，下面是笔者列举的一些内容。
功能性的需求：
（1）哪些业务数据需要提供全文的检索服务？
（2）这些业务数据中那些关键信息是业务人员关心的？
（3）需要支持哪些国家的语言？
（4）有哪些行业术语、常用缩略词、替换词？
（5）需要哪些检索功能，分别基于什么范畴的关键字展开检索？
非功能性的需求：
（1）业务上以前是否尝试过关系数据库查询、多维数据分析解决手头的问题？
（2）检索时效性要求。
（3）习惯的检索操作平台（浏览器 / 桌面），查询结果的展示方式。
（4）授权控制。
（5）查询结果的导出和发布方式要求。
作者：IT168 王翔 2006-10-18
1. 前言
1.1 应用背景
随着我国*和企业信息化的快速普及和发展，来自于供应链、企业生产系统、办公自动化（或公文行文）系统、人事绩效系统、财务管理系统等无一不在积累着各类数据。不仅如此，来自于企业门户网站、通过各种手持移动设备传递的会议通知、保存在业务员笔记本和PDA中的离线产品报价和短期个人销售信息也不一而足。可以说信息无处不在、无时不在、无设备不在，但是它们是否可以在您的手中，即*和企业的信息系统是否可以把员工需要的信息呈送到他们的指尖之下，这恐怕是另一回事了。信息化普遍实施后，数据获取方式、获取手段的局限，是国内信息化建设主要面临的尴尬现状。
图1：Your Data,Any Where、Any Time、Any Device. But not on your finger.
1.2 主要检索技术的区别
有了数据但是没有被使用，那么这些数据不应该被称为信息。它们无非是不断充斥设备和网络的比特而已，但是如何把数据提供给必要的人员，检索技术是其中非常有效的途径之一。本文笔者主要基于微软平台，针对SQL Server 2005提供的全文检索技术进行介绍。与关系数据查询、多维数据库查询和基于XML的XQuery、XPath不同，全文检索技术主要处理对象是基于超大数据量的文本数据和结构化的二进制数据上类似LIKE的模糊查询。主要区别见下表。
关系数据库查询 多维数据查询 XML查询 全文检索
检索技术 SQL MDX XQuery、XPath SQL (extension)
主要处理对象 关系二维数据 结构化多维数据 层次型数据 大容量二维和层次型数据的模糊检索
主要应用领域 一般的OLTP类应用 一般的OLAP类分析型应用 面向Internet、Intranet的松散耦合SOA应用 企业内部知识管理类应用
索引 大量使用非聚簇索引，一般保存在数据库中。 通过层次型、保存中间结果的方式，通过不同的轴向快速定位信息剖面。 基于XPath的索引，索引一般保存在数据库中。 基于关键字的索引，保存在文件系统中。每个表仅支持一个索引。
表1：全文检索与关系数据库查询、多维数据查询、XML查询的对比
2. 全文检索技术简要介绍
2.1 基本概念
如上文所说，全文检索主要应用领域如下：
（1）大数据量、超大数据量的结构化平文本数据和模糊匹配查找（Char、Varchar、Nvarchar）。
（2）大数据量、超大数据量的层次型XML数据展开后的查找---含模糊查找（Xml type）。
（3）标准格式的二进制非结构化Word数据的查找（VarBinary[max]、Image）。
与其他检索技术不同的是，全文检索不仅仅提供词汇层次的查询支持，而且可以根据语言环境、不同语言的特点，甚至于用户自定义的配置提供不同语义级的大容量数据模糊匹配检索支持。为了提供语义层次的检索，SQL Server 2005的全文检索明确了如下几个概念：
（1）断字符（Word Breaker）：因为对于不同的语言，哪些符号可以用于词汇的分割是不同的，因此全文检索支持不同语言环境的不同断字符。
（2）标记（Token）：是由断字符标识的词或字符串。由于划分是基于特定语言完成的，因此也可以做到语义层次的支持。
（3）干扰词（Noise Word）：主要是那些经常出现，但是对于检索没有多少帮助的词汇。例如：英语中的“a”、 “and”、 “is”、 “the”，汉语中的“的”、 “不”、 “以”、 “了”等。SQL Server 2005中提供配置文件，允许用户自定义自己语言、甚至与本行业、本企业的检索干扰词。
（4）词干分析器（Stemmer）：通过断字符分割后，根据具体的语言和该语言的语法规程生成的特定词汇的变形。
（5）同义词：即便是同一个语言，在检索的情况下也存在同义词如何处理的问题。如果一个检索系统不能够识别近义词，而只能识别完全匹配的词汇，那对于我们中文这种表义的语言而言会带来很大不便。同样的，一个行业内部也有很多同义词或者是缩略语。例如如下的词语。
广播行业 ： “ABC”与“英国ABC广播公司”基本上类似，但是也可能和“澳大利亚广播公司”混淆。
*行文： “ABC”与南美的“阿根廷、巴西、智利三国”是同义词。
军事领域： “ABC”与“原子、生物、化学战”同义。
不仅如此，由于日常使用的习惯，我们在口语表达和书面语表达上也有区别，这个也需要预先定义。例如，很多口头常用的技术产品“Win2K”、 “WinXP”等，虽然说起来很习惯，但是在行文的时候，一般都很正式的称为“Windows 2000”和 “Windows XP”，因此SQL Server 2005上也提供类似词汇替换的支持，而且这些支持也是与具体语言相关的。
2.2 SQL Server 2005全文检索的技术架构
SQL Server 2005的全文检索其实是由三个进程共同完成的，它们的总体逻辑架构如下：
图2：SQL Server 2005的总体逻辑架构
其中，三个进程分别为：
（1）SQL Server process (Sqlservr.exe)
（2）Microsoft Full-Text Engine for SQL Server process (Msftesql.exe)
（3）Microsoft Full-Text Engine Filter Daemon process (Msftefd.exe)
Msftefd主要是负责监控Msftesql进程，同时从具体的数据源根据通过使用对应的过滤器，把其中的文本信息根据断字符拆分成词汇列表（Wordlist）反馈给Msftesql进程。整个全文检索的简要执行过程如下：
（1）从客户端发送的全文查询会转到 SQL Server 进程中的 SQL Server 查询处理器 。
（2）查询处理器再将它传递给全文查询组件，该组件将创建 OLE DB 命令树，并将它发送到 Microsoft Full-Text Engine for SQL Server (MSFTESQL) 服务。
（3）在 MSFTESQL 进程中，全文引擎查询处理器将使用同义词库和干扰词文件以及断字符和词干分析器来处理查询。
（4）处理此查询之后，MSFTESQL 服务将结果集返回到 SQL Server 进程。此结果集可以用于进一步进行处理，也可以返回到客户端。
3. 规划您的全文检索
由于全文检索概念相对较多，与多数读者日常接触的关系数据库查询有所区别，因此上文笔者简单介绍了SQL Server全文检索技术的几个要点，下面笔者介绍一下面对国际化趋势，在本*或企业的分布式异构信息系统环境下，如何规划全文检索服务的建设。
3.1 全文检索服务的需求收集
抛开其他需求分析内容不谈，仅全文检索服务自身就有很多特定的需求需要明确，下面是笔者列举的一些内容。
功能性的需求：
（1）哪些业务数据需要提供全文的检索服务？
（2）这些业务数据中那些关键信息是业务人员关心的？
（3）需要支持哪些国家的语言？
（4）有哪些行业术语、常用缩略词、替换词？
（5）需要哪些检索功能，分别基于什么范畴的关键字展开检索？
非功能性的需求：
（1）业务上以前是否尝试过关系数据库查询、多维数据分析解决手头的问题？
（2）检索时效性要求。
（3）习惯的检索操作平台（浏览器 / 桌面），查询结果的展示方式。
（4）授权控制。
（5）查询结果的导出和发布方式要求。
#2
3.2 全文检索服务的需求分析
作为系统分析人员，在收集到这些信息后，需要从技术的角度考虑现有的技术储备是否可以完成业务的要求，根据上面的业务需求，下面是笔者认为需要考虑的技术要点：
（1）是否真的有必要使用全文检索技术，以往的关系数据库查询、多维数据分析、XML数据检索是否可以满足上述功能。
（2）用户要求的数据是否分布在不同的系统中，是否分布在不同的数据库上。
（3）数据源是否位于异构的操作系统和数据库上。
（4）不同语言的信息如何存储呢，拆分到不同的表，还是在应用层合并。还是直接通过跨语言的同义词解决不同语言之上的关键词查找。
（5）如何选择现成的产品来集成，并完成操作台开发、信息发布、查询结果导出。
（6）通过数据库授权、证书系统授权还是应用自定义授权解决访问的安全性。
3.3 数据源的规划
SQL Server 2005可以同时支持如下三种数据：
（1）Char、Varchar、Nvarchar
（2）XML
（3）VarBinary（max）、Image
对于第一种，由于都是SQL Server的内置类型，因此数据提取很容易。对于后两种，为了保证Word、Excel、Power Point之类的格式化二进制数据可以被检索，一般在规划上还要增加伪列来标明对应的文件扩展名。这样，可以保证SQL Server 2005全文检索的过滤器可以从对应的文件中提取出需要的文本内容，并把它通过断字符拆分成有效的词汇列表（Wordlist）。集成方式如下：
图3：标准VarBinary(max)、Image、XML类型的集成方式
通过查询视图sys.fulltext_document_types可以获得已经安装的过滤器（即支持的文档类型），下面是现有SQL Server 2005默认支持的文档类型：
（1）.ascx、.asm、.asp、.aspx、.bat、.c、
（2）.cmd、.cpp、.cxx、.def、.dic、.doc、
（3）.dot、.h、.hhc、.hpp、.htm、.html、
（4）.htw、.htx、.hxx、.ibq、.idl、.inc、
（5）.inf、.ini、.inx、.js、.log、.m3u、.mht、
（6）.obd、.obt、.odc、.pl、.pot、.ppt、.rc、
（7）.reg、.rtf、.stm、.txt、.url、.vbs、.wtx、
（8）.xlb、.xlc、.xls、.xlt、.xml
对于远程的SQL Server， 可以通过链接服务器方式访问远端数据源的全文检索系统。若要对链接服务器执行全文查询，必须先对远程服务器上的目标表和列创建全文索引。然后，将远程服务器添加为链接服务器。完成这些操作后，可以在包括CONTAINS 或 FREETEXT 这些全文查询的语句中使用，不过检索对象的命名是由四部分组成的名称对链接服务器上的目标表和列进行查询。
此外，对于以往保存在Oracle、DB2、MySQL等数据库产品上的text、image数据，也可以通过SQL Server的复制或者集成服务来进行数据同步。这个同步要根据文本内容的更新频率、业务许可间隔、数据类型进行配置。常用的同步方式如下：
（1）通过SQL Job，基于 ODBC/OLEDB 的分布式查询定期更新。该方式可以视为从SQL Server端，定期批量从异构数据库“拉”出数据。
（2）通过IIOP、HTTP、Trigger + JOB、External Server等方式向SQL Server写入。该方式可以视为异构数据库根据配置定期向SQL Server端写入，即向SQL Server “推”数据。
（3）复制：该方式可以提供更为实时的同步，即可以通过具有事务性（Transactional）的单票数据更新实现，也属于向SQL Server “推”数据。
（4）通过中间介质 Export / Import：通过平文本之类的中间介质，配合FTP、Queue等发送方式，完成异构数据库的导出和SQL Server端的异步入库。
图4：异构数据库与SQL Server的同步方式
另外，对于大型的*行业和企业而言，还存在多数据中心间的全文检索数据源同步的问题。对于这种远程的系统，异构数据源的导入要本着就近原则，全文检索上需要考虑尽量在集中的某个中心上执行。
图5：多数据中心的全文检索部署体系
说明如下：每个中心内部的异构数据源的导入在本数据中心内部完成；不同数据中心间通过双向的Linked Server完成；但是对于每个点视为其他中心对自己的单向Linked Server；客户端全文检索在就近的SQL Server 2005服务器上执行。
3.4 引入*行业或者企业自身的的数据字典
为了让SQL Server 2005的全文检索更适于本*行业或者企业使用，还需要把自己特色的缩略语、书面替换语进行配置。但是，在此之前，还要把主要使用的语言的相关信息进行配置，主要是配置相关的断字符和干扰字。
SQL Server 2005的断字符配置是根据语言分析规则而异，可以为每个全文索引列指定不同的语言。每种语言的断字符能够使得为该语言生成的词更加准确。如果断字符用于整个语系而不是特定的子语言，将使用该语系中的主要语言。例如，使用法语断字符来处理加拿大法语文本。如果某一特定语言没有可用的断字符，将使用非特定语言断字符。使用非特定语言断字符时，词将在非特定语言字符（如空格和标点符号）处断开。
SQL Server 2005 包含 23 种区域设置的断字符。通过参阅 sys.fulltext_languages 就可以获得所有支持语言的列表。
地区编号 语言
2052 Simplified Chinese
1028 Traditional Chinese
1031 German
2057 British English
1033 English
3082 Spanish
1036 French
1040 Italian
1041 Japanese
1042 Korean
0 Neutral
1043 Dutch
1053 Swedish
1054 Thai
3076 Chinese (Hong Kong SAR, PRC)
5124 Chinese (Macau SAR)
4100 Chinese (Singapore)
表2：SQL Server 2005支持的23种区域语言
注：所查询的全文索引列的语言决定了对 CONTAINS、FREETEXT、CONTAINSTABLE 和 FREETEXTTABLE 等全文查询函数的参数执行的语言分析。如果未指定列的语言，默认值是配置选项 default full-text language 的值。对于SQL Server 2005的本地版本，SQL Server 安装程序将把 default full-text language 选项设置为操作系统使用的语言；对于 SQL Server 的非本地化版本，default full-text language 选项为“英语”。
在明确了区域语言之后，还需要进行本*行业或者企业的定制化操作：
（1）在$<SQL Server Install Path>\Microsoft SQL Server\MSSQL.1\MSSQL\FTDATA\中配置对应的干扰词，可以在对应的noise***.文件中增加或者修改干扰词。
例如，对以一家IT公司而言，查询的时候就直接说服务器的名字，而把 “服务器”作为干扰词，查询某个网站的时候也就直接称呼网站的名字，把“网站”也可以作为干扰词。
（2）更为重要的是配置自己的同义词和替换词，同样在$<SQL Server Install Path>\Microsoft SQL Server\MSSQL.1\MSSQL\FTDATA\中配置对应区域语言的ts***.xml文件即可。
例如，把tsCHS.xml修改为如下内容：
<?xml version="1.0" encoding="utf-8"?>
<XML ID="Microsoft Search Thesaurus">
<thesaurus xmlns="x-schema:tsSchema.xml">
<diacritics_sensitive>0</diacritics_sensitive>
<expansion>
<sub>Internet Explorer</sub>
<sub>IE</sub>
<sub>IE5</sub>
</expansion>
<replacement>
<pat>NT5</pat>
<pat>W2K</pat>
<sub>Windows 2000</sub>
</replacement>
<expansion>
<sub>北京站</sub>
<sub>北京火车站</sub>
<sub>北京东站</sub>
</expansion>
</thesaurus>
</XML>
对于同义词在检索的时候，如果用户的查询关键字是“北京站”，那么记录内容为“北京火车站”和“北京东站”的信息也会被查询出来；对于替换词，如果用户查找的是“NT5”或“W2K”的时候，只有包括“Windows 2000”的内容会被提取出来，而 包括“NT5”或“W2K”自身的内容反而不会被提取出来。
4. 设计全文检索的统一视图
4.1设计统一的全文检索结果Schema
如果要实现统一的检索视图，第一步要从后端统一检索结果的Schema。笔者这里设计一个简易的Schema，另外预留一个扩展字段，作为各种信息的扩展需要。设计上该扩展字段最好设计为XML类型，因为一方面它是可以进一步扩展的，另一方面它也是结构良好的，可以通过Xpath的索引快速查询。Schema如下：
图6：一个统一的查询结果Schema
说明如下。
URL：定义信息的来源。
Title：定义检索到的信息的Title（文章标题、数据信息的说明内容）。
DocumentType：定义检索结果的文档类型。
Content：定义包括关键字的一个相关的句子内容。
InventoryDate：定义该检索内容的入库登记时间。
Extension：扩展信息。
例如，如果您的全文检索系统是面向采购的，那么这个Extensionn您可以用来保存联系人的各种信息。设计上首先可以定义该字段的XSD，然后通过这个XSD对输入的数据进行验证，下面是笔者给出的一个示例XSD和示例Extension内容。
作为系统分析人员，在收集到这些信息后，需要从技术的角度考虑现有的技术储备是否可以完成业务的要求，根据上面的业务需求，下面是笔者认为需要考虑的技术要点：
（1）是否真的有必要使用全文检索技术，以往的关系数据库查询、多维数据分析、XML数据检索是否可以满足上述功能。
（2）用户要求的数据是否分布在不同的系统中，是否分布在不同的数据库上。
（3）数据源是否位于异构的操作系统和数据库上。
（4）不同语言的信息如何存储呢，拆分到不同的表，还是在应用层合并。还是直接通过跨语言的同义词解决不同语言之上的关键词查找。
（5）如何选择现成的产品来集成，并完成操作台开发、信息发布、查询结果导出。
（6）通过数据库授权、证书系统授权还是应用自定义授权解决访问的安全性。
3.3 数据源的规划
SQL Server 2005可以同时支持如下三种数据：
（1）Char、Varchar、Nvarchar
（2）XML
（3）VarBinary（max）、Image
对于第一种，由于都是SQL Server的内置类型，因此数据提取很容易。对于后两种，为了保证Word、Excel、Power Point之类的格式化二进制数据可以被检索，一般在规划上还要增加伪列来标明对应的文件扩展名。这样，可以保证SQL Server 2005全文检索的过滤器可以从对应的文件中提取出需要的文本内容，并把它通过断字符拆分成有效的词汇列表（Wordlist）。集成方式如下：
图3：标准VarBinary(max)、Image、XML类型的集成方式
通过查询视图sys.fulltext_document_types可以获得已经安装的过滤器（即支持的文档类型），下面是现有SQL Server 2005默认支持的文档类型：
（1）.ascx、.asm、.asp、.aspx、.bat、.c、
（2）.cmd、.cpp、.cxx、.def、.dic、.doc、
（3）.dot、.h、.hhc、.hpp、.htm、.html、
（4）.htw、.htx、.hxx、.ibq、.idl、.inc、
（5）.inf、.ini、.inx、.js、.log、.m3u、.mht、
（6）.obd、.obt、.odc、.pl、.pot、.ppt、.rc、
（7）.reg、.rtf、.stm、.txt、.url、.vbs、.wtx、
（8）.xlb、.xlc、.xls、.xlt、.xml
对于远程的SQL Server， 可以通过链接服务器方式访问远端数据源的全文检索系统。若要对链接服务器执行全文查询，必须先对远程服务器上的目标表和列创建全文索引。然后，将远程服务器添加为链接服务器。完成这些操作后，可以在包括CONTAINS 或 FREETEXT 这些全文查询的语句中使用，不过检索对象的命名是由四部分组成的名称对链接服务器上的目标表和列进行查询。
此外，对于以往保存在Oracle、DB2、MySQL等数据库产品上的text、image数据，也可以通过SQL Server的复制或者集成服务来进行数据同步。这个同步要根据文本内容的更新频率、业务许可间隔、数据类型进行配置。常用的同步方式如下：
（1）通过SQL Job，基于 ODBC/OLEDB 的分布式查询定期更新。该方式可以视为从SQL Server端，定期批量从异构数据库“拉”出数据。
（2）通过IIOP、HTTP、Trigger + JOB、External Server等方式向SQL Server写入。该方式可以视为异构数据库根据配置定期向SQL Server端写入，即向SQL Server “推”数据。
（3）复制：该方式可以提供更为实时的同步，即可以通过具有事务性（Transactional）的单票数据更新实现，也属于向SQL Server “推”数据。
（4）通过中间介质 Export / Import：通过平文本之类的中间介质，配合FTP、Queue等发送方式，完成异构数据库的导出和SQL Server端的异步入库。
图4：异构数据库与SQL Server的同步方式
另外，对于大型的*行业和企业而言，还存在多数据中心间的全文检索数据源同步的问题。对于这种远程的系统，异构数据源的导入要本着就近原则，全文检索上需要考虑尽量在集中的某个中心上执行。
图5：多数据中心的全文检索部署体系
说明如下：每个中心内部的异构数据源的导入在本数据中心内部完成；不同数据中心间通过双向的Linked Server完成；但是对于每个点视为其他中心对自己的单向Linked Server；客户端全文检索在就近的SQL Server 2005服务器上执行。
3.4 引入*行业或者企业自身的的数据字典
为了让SQL Server 2005的全文检索更适于本*行业或者企业使用，还需要把自己特色的缩略语、书面替换语进行配置。但是，在此之前，还要把主要使用的语言的相关信息进行配置，主要是配置相关的断字符和干扰字。
SQL Server 2005的断字符配置是根据语言分析规则而异，可以为每个全文索引列指定不同的语言。每种语言的断字符能够使得为该语言生成的词更加准确。如果断字符用于整个语系而不是特定的子语言，将使用该语系中的主要语言。例如，使用法语断字符来处理加拿大法语文本。如果某一特定语言没有可用的断字符，将使用非特定语言断字符。使用非特定语言断字符时，词将在非特定语言字符（如空格和标点符号）处断开。
SQL Server 2005 包含 23 种区域设置的断字符。通过参阅 sys.fulltext_languages 就可以获得所有支持语言的列表。
地区编号 语言
2052 Simplified Chinese
1028 Traditional Chinese
1031 German
2057 British English
1033 English
3082 Spanish
1036 French
1040 Italian
1041 Japanese
1042 Korean
0 Neutral
1043 Dutch
1053 Swedish
1054 Thai
3076 Chinese (Hong Kong SAR, PRC)
5124 Chinese (Macau SAR)
4100 Chinese (Singapore)
表2：SQL Server 2005支持的23种区域语言
注：所查询的全文索引列的语言决定了对 CONTAINS、FREETEXT、CONTAINSTABLE 和 FREETEXTTABLE 等全文查询函数的参数执行的语言分析。如果未指定列的语言，默认值是配置选项 default full-text language 的值。对于SQL Server 2005的本地版本，SQL Server 安装程序将把 default full-text language 选项设置为操作系统使用的语言；对于 SQL Server 的非本地化版本，default full-text language 选项为“英语”。
在明确了区域语言之后，还需要进行本*行业或者企业的定制化操作：
（1）在$<SQL Server Install Path>\Microsoft SQL Server\MSSQL.1\MSSQL\FTDATA\中配置对应的干扰词，可以在对应的noise***.文件中增加或者修改干扰词。
例如，对以一家IT公司而言，查询的时候就直接说服务器的名字，而把 “服务器”作为干扰词，查询某个网站的时候也就直接称呼网站的名字，把“网站”也可以作为干扰词。
（2）更为重要的是配置自己的同义词和替换词，同样在$<SQL Server Install Path>\Microsoft SQL Server\MSSQL.1\MSSQL\FTDATA\中配置对应区域语言的ts***.xml文件即可。
例如，把tsCHS.xml修改为如下内容：
<?xml version="1.0" encoding="utf-8"?>
<XML ID="Microsoft Search Thesaurus">
<thesaurus xmlns="x-schema:tsSchema.xml">
<diacritics_sensitive>0</diacritics_sensitive>
<expansion>
<sub>Internet Explorer</sub>
<sub>IE</sub>
<sub>IE5</sub>
</expansion>
<replacement>
<pat>NT5</pat>
<pat>W2K</pat>
<sub>Windows 2000</sub>
</replacement>
<expansion>
<sub>北京站</sub>
<sub>北京火车站</sub>
<sub>北京东站</sub>
</expansion>
</thesaurus>
</XML>
对于同义词在检索的时候，如果用户的查询关键字是“北京站”，那么记录内容为“北京火车站”和“北京东站”的信息也会被查询出来；对于替换词，如果用户查找的是“NT5”或“W2K”的时候，只有包括“Windows 2000”的内容会被提取出来，而 包括“NT5”或“W2K”自身的内容反而不会被提取出来。
4. 设计全文检索的统一视图
4.1设计统一的全文检索结果Schema
如果要实现统一的检索视图，第一步要从后端统一检索结果的Schema。笔者这里设计一个简易的Schema，另外预留一个扩展字段，作为各种信息的扩展需要。设计上该扩展字段最好设计为XML类型，因为一方面它是可以进一步扩展的，另一方面它也是结构良好的，可以通过Xpath的索引快速查询。Schema如下：
图6：一个统一的查询结果Schema
说明如下。
URL：定义信息的来源。
Title：定义检索到的信息的Title（文章标题、数据信息的说明内容）。
DocumentType：定义检索结果的文档类型。
Content：定义包括关键字的一个相关的句子内容。
InventoryDate：定义该检索内容的入库登记时间。
Extension：扩展信息。
例如，如果您的全文检索系统是面向采购的，那么这个Extensionn您可以用来保存联系人的各种信息。设计上首先可以定义该字段的XSD，然后通过这个XSD对输入的数据进行验证，下面是笔者给出的一个示例XSD和示例Extension内容。
#3
图6：联系人的示例XSD和一个示例的数据
URL Title Doc
Type
Content Inventory
Date
Extension
Http://
www.ViT.com
Full-text
Data
Definition
Language
PDF Microsoft SQL Server 2005 introduces new Transact-SQL data definition language (DDL) statements for creating, implementing, and managing full-text catalogs and indexes. The following is a list of the new Full-Text Search DDL statements.
4.2 多个全文检索结果的前期设计
受到全文检索仅仅支持单个表的限制，每个全文检索的结果相对有限。但是，对于用户而言他们常常做的是一个模糊的关键词在通盘信息中的检索，这些工作应该由开发人员在应用层通过搜索引擎帮助用户进行后台的合并。此外，对于整个*行业和大型的企业而言，非结构化文本数据和结构化二进制信息资源很可能物理上分散在不同的物理位置上。因此，对于高层的决策者和信息工作者而言，他们也需要查询引擎内部提供检索结果合并的支持。
这里，基于上文笔者提出的统一检索结果Schema，统一全文检索系统需要提供一个配置库，用于保存不同全文检索功能需要把哪些检索命令的执行结果进行合并，此外考虑到个别高级用户的需要，还需要提供给这一部分用户Ad-Hoc同时全文检索多个数据内容（甚至是多个信息源）的支持。为了说明这个数据合并的过程，这里笔者假设了一个业务应用情形：
? （1）AdventureWorks公司的高管、人事、财务等部门位于A城的总部（Headquarter），使用的是SQL Server 2005。
? （2）AdventureWorks公司的仓库位于B城，但是生产系统与总部是互联的，使用的是SQL Server 2005。
? （3）AdventureWorks公司的1号工厂位于C城，但是生产系统与总部是互联的，使用的是SQL Server 2005。
? （4）AdventureWorks公司最近收购了Northwind的工厂，作为它的2号工厂，这个工厂也位于B城，但是生产系统与AdventureWorks总部和原有的仓库也是互联的，使用的是Oracle 9i，但是产品信息很少，相关产品绝大多数都是在本地销售。
图7：示例应用的地理分布关系
那么根据各地的信息，如果要查询和“中国”相关的信息，各自相关的全文检索命令类似下表。
ID
编号 Title
检索内容 Site 位置 DB
数据库 Command
检索命令示例
Q_01 A点人事信息 A Adventureworks SELECT Comments，StartWorkDate
FROM <prefix>HR.Employee
WHERE CONTAINS(Comments, ' "from china" ');
GO
Q_02 A点财务信息 A Adventureworks SELECT Notes，AccountDate
FROM <prefix>Finance.Expanse
WHERE CONTAINS（Notes, ' " china" ');
GO
Q_03 B点仓库信息 B Adventureworks SELECT Note, RegisterDate
FROM <prefix>Warehouse.Inventory
WHERE CONTAINS(Note, ' "from china" ');
GO
Q_04 2号工厂的产品信息。
（已将Oracle的信息导入到SQL Server 2005的Northwind数据库）
B Northwind SELECT COMMENT, INPUT_DATE
FROM <prefix>PRODUCT_LIST
WHERE ORIGINAL_COUNTRY = 'CHINA'
GO
Q_05 1号工厂的产品信息 C Adventureworks SELECT Note, InputDate
FROM <prefix>Production.Producct
WHERE CONTAINS(Note, ' "from china" ');
GO
表3：查询的配置表 (Q : Query)
说明如下。
这里既有全文检索也有关系数据库查询，例如：由于Northwind由于产品信息很少，而且登记产品的时候还登记了产品的来源国，所以完全可以通过关系数据库查询完成检索工作。
? 其他全文检索的示例都采用的是本地搜索特定词或短语（简单词条）的方式。
? 与可以直接执行的语句不同，这里每个查询的FROM对象前面还有个<prefix>，它的内容会根据查询是本地还是远程链接服务器在运行态动态修改的。
如果想要高管要在A城检索全部的人事信息、财务信息、产品信息，根据上面讨论需要增加一系列统一查询结果的配置登记。
1． 链接服务器登记表
ID
编号
Name
名称 From
从 To
至 DB
数据库 Comment 检索命令示例
LS_01 LSAtoBwithAdventureworks A B Adventureworks A城SQL Server到B城SQL Server Adventureworks数据库的连接服务器
LS_02 LSAtoBwithNorthwind A B Northwind A城SQL Server到B城SQL Server Northwind数据库的连接服务器
LS_03 LSAtoCwithAdventureworks A C Adventureworks A城SQL Server到C城SQL Server Adventureworks数据库的连接服务器
LS_04 LSCtoAwithAdventureworks C A Adventureworks C城SQL Server到A城SQL Server Adventureworks数据库的连接服务器
LS_05 LSBtoAwithAdventureworks B A Adventureworks B城SQL Server到A城SQL Server Adventureworks数据库的连接服务器
表：连接服务器登记表 (LS : Linked Server)
2． 查询结果统一化登记表
这里为了所有的操作都可以配置化，同时为了提高开发库的重用性，笔者采用了XSD-〉XSLT->XSD的描述方式。
注：当然，读者也完全可以通过配置专用的转换Assembly + Class完成，只不过如果交换的全文检索内容很多的话，需要重复进行很多开发工作。
上文笔者统一化的查询结果Schema用XSD表示如下：
图8：统一化的全文检索查询结果Schema
注：用Stylus Studio XML Enterprise Edition的XML Designer显示的结果。
以查询结果Q_01为例，如果要把它统一化，那么需要在全文检索的结果中增加几个查询配置表的内容作为占位伪列（Placeholder column）。然后，与统一检索结果Schema的映射关系如下：
url ：http:// hr.adventureworks.com
title ：人事信息
documentType：DB
content：查询结果的Comments字段
inventoryDate：查询结果的StartWorkDate字段
extension：null
处理上，仅需要配置一个如下映射关系的XSLT就可以完成：
图9：把查询Q_01的结果影射为统一化查询结果Schema的XSLT
3． 业务检索登记表
ID
编号
Step
查询组成步骤
Q_ID
查询编号
Converter
转换关系
BQ_AllProduct 1 Q_04 .......
BQ_AllProduct 2 Q_05 .......
BQ_QueryHr 1 Q_01 <?xml version='1.0' ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<unifiedFullTextResult url="http://hr.adventureworks.com" title="人事信息" documentType="DB" extension="null">
<xsl:attribute name="content">
<xsl:value-of select="hrQuery/@Comment"/>
</xsl:attribute>
<xsl:attribute name="inventoryDate">
<xsl:value-of select="hrQuery/@StartWorkDate"/>
</xsl:attribute>
</unifiedFullTextResult>
</xsl:template>
</xsl:stylesheet>
URL Title Doc
Type
Content Inventory
Date
Extension
Http://
www.ViT.com
Full-text
Data
Definition
Language
PDF Microsoft SQL Server 2005 introduces new Transact-SQL data definition language (DDL) statements for creating, implementing, and managing full-text catalogs and indexes. The following is a list of the new Full-Text Search DDL statements.
4.2 多个全文检索结果的前期设计
受到全文检索仅仅支持单个表的限制，每个全文检索的结果相对有限。但是，对于用户而言他们常常做的是一个模糊的关键词在通盘信息中的检索，这些工作应该由开发人员在应用层通过搜索引擎帮助用户进行后台的合并。此外，对于整个*行业和大型的企业而言，非结构化文本数据和结构化二进制信息资源很可能物理上分散在不同的物理位置上。因此，对于高层的决策者和信息工作者而言，他们也需要查询引擎内部提供检索结果合并的支持。
这里，基于上文笔者提出的统一检索结果Schema，统一全文检索系统需要提供一个配置库，用于保存不同全文检索功能需要把哪些检索命令的执行结果进行合并，此外考虑到个别高级用户的需要，还需要提供给这一部分用户Ad-Hoc同时全文检索多个数据内容（甚至是多个信息源）的支持。为了说明这个数据合并的过程，这里笔者假设了一个业务应用情形：
? （1）AdventureWorks公司的高管、人事、财务等部门位于A城的总部（Headquarter），使用的是SQL Server 2005。
? （2）AdventureWorks公司的仓库位于B城，但是生产系统与总部是互联的，使用的是SQL Server 2005。
? （3）AdventureWorks公司的1号工厂位于C城，但是生产系统与总部是互联的，使用的是SQL Server 2005。
? （4）AdventureWorks公司最近收购了Northwind的工厂，作为它的2号工厂，这个工厂也位于B城，但是生产系统与AdventureWorks总部和原有的仓库也是互联的，使用的是Oracle 9i，但是产品信息很少，相关产品绝大多数都是在本地销售。
图7：示例应用的地理分布关系
那么根据各地的信息，如果要查询和“中国”相关的信息，各自相关的全文检索命令类似下表。
ID
编号 Title
检索内容 Site 位置 DB
数据库 Command
检索命令示例
Q_01 A点人事信息 A Adventureworks SELECT Comments，StartWorkDate
FROM <prefix>HR.Employee
WHERE CONTAINS(Comments, ' "from china" ');
GO
Q_02 A点财务信息 A Adventureworks SELECT Notes，AccountDate
FROM <prefix>Finance.Expanse
WHERE CONTAINS（Notes, ' " china" ');
GO
Q_03 B点仓库信息 B Adventureworks SELECT Note, RegisterDate
FROM <prefix>Warehouse.Inventory
WHERE CONTAINS(Note, ' "from china" ');
GO
Q_04 2号工厂的产品信息。
（已将Oracle的信息导入到SQL Server 2005的Northwind数据库）
B Northwind SELECT COMMENT, INPUT_DATE
FROM <prefix>PRODUCT_LIST
WHERE ORIGINAL_COUNTRY = 'CHINA'
GO
Q_05 1号工厂的产品信息 C Adventureworks SELECT Note, InputDate
FROM <prefix>Production.Producct
WHERE CONTAINS(Note, ' "from china" ');
GO
表3：查询的配置表 (Q : Query)
说明如下。
这里既有全文检索也有关系数据库查询，例如：由于Northwind由于产品信息很少，而且登记产品的时候还登记了产品的来源国，所以完全可以通过关系数据库查询完成检索工作。
? 其他全文检索的示例都采用的是本地搜索特定词或短语（简单词条）的方式。
? 与可以直接执行的语句不同，这里每个查询的FROM对象前面还有个<prefix>，它的内容会根据查询是本地还是远程链接服务器在运行态动态修改的。
如果想要高管要在A城检索全部的人事信息、财务信息、产品信息，根据上面讨论需要增加一系列统一查询结果的配置登记。
1． 链接服务器登记表
ID
编号
Name
名称 From
从 To
至 DB
数据库 Comment 检索命令示例
LS_01 LSAtoBwithAdventureworks A B Adventureworks A城SQL Server到B城SQL Server Adventureworks数据库的连接服务器
LS_02 LSAtoBwithNorthwind A B Northwind A城SQL Server到B城SQL Server Northwind数据库的连接服务器
LS_03 LSAtoCwithAdventureworks A C Adventureworks A城SQL Server到C城SQL Server Adventureworks数据库的连接服务器
LS_04 LSCtoAwithAdventureworks C A Adventureworks C城SQL Server到A城SQL Server Adventureworks数据库的连接服务器
LS_05 LSBtoAwithAdventureworks B A Adventureworks B城SQL Server到A城SQL Server Adventureworks数据库的连接服务器
表：连接服务器登记表 (LS : Linked Server)
2． 查询结果统一化登记表
这里为了所有的操作都可以配置化，同时为了提高开发库的重用性，笔者采用了XSD-〉XSLT->XSD的描述方式。
注：当然，读者也完全可以通过配置专用的转换Assembly + Class完成，只不过如果交换的全文检索内容很多的话，需要重复进行很多开发工作。
上文笔者统一化的查询结果Schema用XSD表示如下：
图8：统一化的全文检索查询结果Schema
注：用Stylus Studio XML Enterprise Edition的XML Designer显示的结果。
以查询结果Q_01为例，如果要把它统一化，那么需要在全文检索的结果中增加几个查询配置表的内容作为占位伪列（Placeholder column）。然后，与统一检索结果Schema的映射关系如下：
url ：http:// hr.adventureworks.com
title ：人事信息
documentType：DB
content：查询结果的Comments字段
inventoryDate：查询结果的StartWorkDate字段
extension：null
处理上，仅需要配置一个如下映射关系的XSLT就可以完成：
图9：把查询Q_01的结果影射为统一化查询结果Schema的XSLT
3． 业务检索登记表
ID
编号
Step
查询组成步骤
Q_ID
查询编号
Converter
转换关系
BQ_AllProduct 1 Q_04 .......
BQ_AllProduct 2 Q_05 .......
BQ_QueryHr 1 Q_01 <?xml version='1.0' ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<unifiedFullTextResult url="http://hr.adventureworks.com" title="人事信息" documentType="DB" extension="null">
<xsl:attribute name="content">
<xsl:value-of select="hrQuery/@Comment"/>
</xsl:attribute>
<xsl:attribute name="inventoryDate">
<xsl:value-of select="hrQuery/@StartWorkDate"/>
</xsl:attribute>
</unifiedFullTextResult>
</xsl:template>
</xsl:stylesheet>
#4
4.3 多个全文检索结果的合并
在完成了上述准备工作后，就可以在应用上设计实际的合并过程了。步骤如下：
1． 在某一城市的客户端发起了一个全文检索的业务查询请求。
2． 查询引擎根据“业务查询登记表”的内容了解如果完成这个请求，需要执行哪个几个具体查询。
3． 查询引擎带着具体查询列表，通过查询“查询的配置表”了解哪些查询是本地的、哪些查询是远程的，并且获得了模式化的查询命令。
4． 对于数据源位于本地的查询，直接在模式化查询命令上增加 USE <DB> GO子句，并且把<prefix>用空串替换，这样就获得了本地的查询命令。
5． 对于数据源位于远程的查询，还需要通过查询“链接服务器登记表”，了解这个查询需要通过哪个逻辑名称的链接服务器间接查询，并且替换模式化查询命令的USE <DB> GO和<prefix>部分。
6． 当所有的查询命令（本地 / 远程）都准备好了之后，查询引擎并发的把请求提交，并获得了一组非统一化的数据查询结果。
7． 查询引擎根据“业务查询登记表”表中每个查询结果的统一化转换配置，把每个查询结果统一化成为标准的统一Schema。
8． 最后，查询引擎把统一化的查询结果合并。
4.4 合并结果的多样化展示
虽然数据是统一化Schema的，并且内容也是合并的，但是用户UI地展示却应该是多种多样的。对于胖客户端应用，完全可以通过开发不同的User Control，绑定查询结果即可；对于浏览器客户端，更为简单，只需要配置好一个合并结果的XML -> HTML的XSLT就可以自动的把结果绑定并展示为用户需要的形式。
5. 优化SQL Server 2005的全文检索
对于一个企业级的全文检索系统，尤其是笔者上文所设计的多数据中心、异构数据源的全文检索系统，如何在运维过程不断优化系统的执行效率也是很有挑战的工作。由于全文检索过程中不仅涉及大量的IO操作，也存在执行过程中频繁的CPU计算工作，因此这里笔者提供几个关键指标，用于粗略判断系统的关键性能瓶颈。
5.1 CPU
如果由 MSFTESQL 服务和 SQL Server 所占用的 CPU 使用率接近百分之百，则 CPU 成为瓶颈。
Catalog Counter
Processor % Processor Time
% Privileged Time
System Processor Queue Length
Context Switches/sec
表5：判断CPU瓶颈的主要指标
下面对于一台单纯进行全文检索的服务器而言，是一个典型的内存瓶颈结果。
图10：CPU成为系统瓶颈
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）减少应用的并发。
（2）对于大量用户频繁访问的固定内容的全文检索，可以通过Reporting Service把结果内容固定下来，减少用户普遍关心但是结果固定的全文检索查询。
（3）通过SQL Server Cluster，借助Scale out或者Scale up分担负载。
5.2 内存
由于全文检索的过程需要在内容临时存放大量的中间结果，因此内存也很容易成为应用的瓶颈。
Catalog Counter
Memory Available MBytes
Page Reads/sec
Pages/sec
Cache Bytes
Cache Faults/sec
Server Pool Nonpaged Failures
Pool Nonpaged Peak
Cache MDL Read Hits %
表6：判断内存瓶颈的主要指标
下面对于一台单纯进行全文检索的服务器而言，是一个典型的内存瓶颈结果。
图11：内存成为系统瓶颈
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）减少应用的并发。
（2）配置SQL Job，把长时间挂起或者工作时间没有必要的过大查询的session清理。
（3）优化检索语句。
（4）尽量精确限制条件，可能的话尽量在尺寸较小的列上定义全文检索索引。
（5）适当增加内存。
（6）根据用户需要，使用TOP_<N>_BY_RANK，而不是把所有符合条件的内容全部提取。
5.3 磁盘IO
如果平均磁盘等待队列长度多于磁盘头数量的两倍，则磁盘成为瓶颈。主要的解决方法是创建独立于 SQL Server 数据库文件和日志的全文目录。将日志、数据库文件和全文目录分别放在不同的磁盘上。购买运行速度更快的磁盘和使用 RAID 也能帮助改善索引性能。
Catalog Counter
PhysicalDisk Avg. Disk Queue Length
Avg. Disk Read Queue Length
Avg. Disk Write Queue Length
Avg. Disk sec/Read
Avg. Disk sec/Transfer
Disk Writes/sec
表7：判断磁盘IO瓶颈的主要指标
5.4 网络IO
由于上文设计中，很多的采用了基于链接服务器的查询，因此网络IO也可能成为系统的瓶颈。
Catalog Counter
Network Interface Bytes Total/sec
Bytes Received/sec
Bytes Sent/sec
Server Bytes Total/sec
Protocol Protocol_Object\Segments Received/sec
Protocol_Object\Segments Sent/sec
Processor % Interrupt Time
表8：判断网络IO瓶颈的主要指标
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）采用磁盘换网络的方法，将异地数据多个节点间冗余的保存。
（2）把当前Session的多个请求打包，一次性的提交到同一远程数据库。
（3）配置SQL Job，把长时间挂起或者工作时间没有必要的过大查询的session清理。
（4）优化检索语句。
（5）尽量精确限制条件，减少反馈的数据量。
（6）根据用户需要，使用TOP_<N>_BY_RANK，而不是把所有符合条件的内容全部提取，减少反馈的数据量。
5.5 其他说明
此外，官方文档还提供了如下的建议：
（1）使用 ALTER INDEX REORGANIZE 对基表的索引进行碎片整理。
（2）使用 ALTER FULLTEXT CATALOG REORGANIZE 重新组织全文目录。请务必在性能测试之前执行此操作，因为它会导致该目录中全文索引的主合并。
（3）仅选择较小的列作为全文键列。即使支持 900 字节的列，我们也不建议您使用这么大的键列来创建全文索引。
（4）将多个 CONTAINS 谓词合并为一个 CONTAINS 谓词。在 SQL Server 中，您可以在 CONTAINS 查询中指定一个包含若干列的列表。
（5）如果只需要全文键或排名的信息，请分别使用 CONTAINSTABLE 或 FREETEXTTABLE，而不要使用 CONTAINS 或 FREETEXT。
（6）若要限制结果数并提高性能，请使用 FREETEXTTABLE 和 CONTAINSTABLE 语法的 TOP_N_BY_RANK 选项。如果您不是对可能查询到的所有信息都感兴趣，可使用此选项。
（7）检查全文查询计划以确保选择了适当的联接计划。若有必要，可使用一个联接提示或查询提示。如果全文查询中使用了参数，则该参数的第一时间值决定查询计划。可使用 OPTIMIZE FOR 查询提示来强制使用所需值编写查询。这有助于获得确定性查询和更好的性能。
6. 更多的集成选择
当然，SQL Server 2005的全文检索不是微软平台上的唯一选择，其他主要的全文检索技术如下：
（1）Index Server, Indexing Service for Microsoft Windows
（2）Microsoft SharePoint? Portal Server 2001（及后续版本）
（3）Microsoft SQL Server 7.0 、SQL Server 2000、SQL Server 2005
（4）Microsoft Exchange Server 2000（及后续版本）
（5）Microsoft Site Server 3.0
（6）Microsoft Office XP（及后续版本）
对于这些全文检索技术，笔者不准备展开介绍，只不过提醒您的是这些技术既有操作系统内置的也有需要购买服务器端产品才可以获得的，它们的检索对象领域各有不同。不过它们都具有微软平台产品普遍开发比较容易的特点，如果您要提供企业全文检索的同时，还考虑提供用户本地桌面或者是文件服务器、Web服务器内容检索的话，完全不必把它们登记到SQL Server 2005里，直接使用对应的技术通过简单的开发即可，结合笔者上文提供查询结果合并的办法一样可以快速的完成系统集成。
7. 总结
本文笔者简单介绍了SQL Server 2005的全文检索技术，及其如何应用于企业级的检索环境，文章最后还提供了其他微软平台全文检索技术的特性对别，结合关系数据库查询、多维数据分析、XML数据查询，希望您可以参照上文的合并方式真正的把本*行业或者企业内部的信息用起来，真正做到“随时、随地、任何设备上您的数据就在指尖。”
在完成了上述准备工作后，就可以在应用上设计实际的合并过程了。步骤如下：
1． 在某一城市的客户端发起了一个全文检索的业务查询请求。
2． 查询引擎根据“业务查询登记表”的内容了解如果完成这个请求，需要执行哪个几个具体查询。
3． 查询引擎带着具体查询列表，通过查询“查询的配置表”了解哪些查询是本地的、哪些查询是远程的，并且获得了模式化的查询命令。
4． 对于数据源位于本地的查询，直接在模式化查询命令上增加 USE <DB> GO子句，并且把<prefix>用空串替换，这样就获得了本地的查询命令。
5． 对于数据源位于远程的查询，还需要通过查询“链接服务器登记表”，了解这个查询需要通过哪个逻辑名称的链接服务器间接查询，并且替换模式化查询命令的USE <DB> GO和<prefix>部分。
6． 当所有的查询命令（本地 / 远程）都准备好了之后，查询引擎并发的把请求提交，并获得了一组非统一化的数据查询结果。
7． 查询引擎根据“业务查询登记表”表中每个查询结果的统一化转换配置，把每个查询结果统一化成为标准的统一Schema。
8． 最后，查询引擎把统一化的查询结果合并。
4.4 合并结果的多样化展示
虽然数据是统一化Schema的，并且内容也是合并的，但是用户UI地展示却应该是多种多样的。对于胖客户端应用，完全可以通过开发不同的User Control，绑定查询结果即可；对于浏览器客户端，更为简单，只需要配置好一个合并结果的XML -> HTML的XSLT就可以自动的把结果绑定并展示为用户需要的形式。
5. 优化SQL Server 2005的全文检索
对于一个企业级的全文检索系统，尤其是笔者上文所设计的多数据中心、异构数据源的全文检索系统，如何在运维过程不断优化系统的执行效率也是很有挑战的工作。由于全文检索过程中不仅涉及大量的IO操作，也存在执行过程中频繁的CPU计算工作，因此这里笔者提供几个关键指标，用于粗略判断系统的关键性能瓶颈。
5.1 CPU
如果由 MSFTESQL 服务和 SQL Server 所占用的 CPU 使用率接近百分之百，则 CPU 成为瓶颈。
Catalog Counter
Processor % Processor Time
% Privileged Time
System Processor Queue Length
Context Switches/sec
表5：判断CPU瓶颈的主要指标
下面对于一台单纯进行全文检索的服务器而言，是一个典型的内存瓶颈结果。
图10：CPU成为系统瓶颈
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）减少应用的并发。
（2）对于大量用户频繁访问的固定内容的全文检索，可以通过Reporting Service把结果内容固定下来，减少用户普遍关心但是结果固定的全文检索查询。
（3）通过SQL Server Cluster，借助Scale out或者Scale up分担负载。
5.2 内存
由于全文检索的过程需要在内容临时存放大量的中间结果，因此内存也很容易成为应用的瓶颈。
Catalog Counter
Memory Available MBytes
Page Reads/sec
Pages/sec
Cache Bytes
Cache Faults/sec
Server Pool Nonpaged Failures
Pool Nonpaged Peak
Cache MDL Read Hits %
表6：判断内存瓶颈的主要指标
下面对于一台单纯进行全文检索的服务器而言，是一个典型的内存瓶颈结果。
图11：内存成为系统瓶颈
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）减少应用的并发。
（2）配置SQL Job，把长时间挂起或者工作时间没有必要的过大查询的session清理。
（3）优化检索语句。
（4）尽量精确限制条件，可能的话尽量在尺寸较小的列上定义全文检索索引。
（5）适当增加内存。
（6）根据用户需要，使用TOP_<N>_BY_RANK，而不是把所有符合条件的内容全部提取。
5.3 磁盘IO
如果平均磁盘等待队列长度多于磁盘头数量的两倍，则磁盘成为瓶颈。主要的解决方法是创建独立于 SQL Server 数据库文件和日志的全文目录。将日志、数据库文件和全文目录分别放在不同的磁盘上。购买运行速度更快的磁盘和使用 RAID 也能帮助改善索引性能。
Catalog Counter
PhysicalDisk Avg. Disk Queue Length
Avg. Disk Read Queue Length
Avg. Disk Write Queue Length
Avg. Disk sec/Read
Avg. Disk sec/Transfer
Disk Writes/sec
表7：判断磁盘IO瓶颈的主要指标
5.4 网络IO
由于上文设计中，很多的采用了基于链接服务器的查询，因此网络IO也可能成为系统的瓶颈。
Catalog Counter
Network Interface Bytes Total/sec
Bytes Received/sec
Bytes Sent/sec
Server Bytes Total/sec
Protocol Protocol_Object\Segments Received/sec
Protocol_Object\Segments Sent/sec
Processor % Interrupt Time
表8：判断网络IO瓶颈的主要指标
根据全文检索的应用经验，处理上主要可以采取如下办法：
（1）采用磁盘换网络的方法，将异地数据多个节点间冗余的保存。
（2）把当前Session的多个请求打包，一次性的提交到同一远程数据库。
（3）配置SQL Job，把长时间挂起或者工作时间没有必要的过大查询的session清理。
（4）优化检索语句。
（5）尽量精确限制条件，减少反馈的数据量。
（6）根据用户需要，使用TOP_<N>_BY_RANK，而不是把所有符合条件的内容全部提取，减少反馈的数据量。
5.5 其他说明
此外，官方文档还提供了如下的建议：
（1）使用 ALTER INDEX REORGANIZE 对基表的索引进行碎片整理。
（2）使用 ALTER FULLTEXT CATALOG REORGANIZE 重新组织全文目录。请务必在性能测试之前执行此操作，因为它会导致该目录中全文索引的主合并。
（3）仅选择较小的列作为全文键列。即使支持 900 字节的列，我们也不建议您使用这么大的键列来创建全文索引。
（4）将多个 CONTAINS 谓词合并为一个 CONTAINS 谓词。在 SQL Server 中，您可以在 CONTAINS 查询中指定一个包含若干列的列表。
（5）如果只需要全文键或排名的信息，请分别使用 CONTAINSTABLE 或 FREETEXTTABLE，而不要使用 CONTAINS 或 FREETEXT。
（6）若要限制结果数并提高性能，请使用 FREETEXTTABLE 和 CONTAINSTABLE 语法的 TOP_N_BY_RANK 选项。如果您不是对可能查询到的所有信息都感兴趣，可使用此选项。
（7）检查全文查询计划以确保选择了适当的联接计划。若有必要，可使用一个联接提示或查询提示。如果全文查询中使用了参数，则该参数的第一时间值决定查询计划。可使用 OPTIMIZE FOR 查询提示来强制使用所需值编写查询。这有助于获得确定性查询和更好的性能。
6. 更多的集成选择
当然，SQL Server 2005的全文检索不是微软平台上的唯一选择，其他主要的全文检索技术如下：
（1）Index Server, Indexing Service for Microsoft Windows
（2）Microsoft SharePoint? Portal Server 2001（及后续版本）
（3）Microsoft SQL Server 7.0 、SQL Server 2000、SQL Server 2005
（4）Microsoft Exchange Server 2000（及后续版本）
（5）Microsoft Site Server 3.0
（6）Microsoft Office XP（及后续版本）
对于这些全文检索技术，笔者不准备展开介绍，只不过提醒您的是这些技术既有操作系统内置的也有需要购买服务器端产品才可以获得的，它们的检索对象领域各有不同。不过它们都具有微软平台产品普遍开发比较容易的特点，如果您要提供企业全文检索的同时，还考虑提供用户本地桌面或者是文件服务器、Web服务器内容检索的话，完全不必把它们登记到SQL Server 2005里，直接使用对应的技术通过简单的开发即可，结合笔者上文提供查询结果合并的办法一样可以快速的完成系统集成。
7. 总结
本文笔者简单介绍了SQL Server 2005的全文检索技术，及其如何应用于企业级的检索环境，文章最后还提供了其他微软平台全文检索技术的特性对别，结合关系数据库查询、多维数据分析、XML数据查询，希望您可以参照上文的合并方式真正的把本*行业或者企业内部的信息用起来，真正做到“随时、随地、任何设备上您的数据就在指尖。”
#5
数据库-> 属性-> 文件-> 使用全文索引 这一选项为什么是灰色的，勾选不了
我已经启动了SQLSERVER Full Text Search 服务了，是不是需要安装其他什么东西。郁闷中，请高手解答
我已经启动了SQLSERVER Full Text Search 服务了，是不是需要安装其他什么东西。郁闷中，请高手解答
#6
MARK
#7
#8
初学sql 跟楼主一样的问题，
#9
跟你一样的问题
那你还把分给粘贴一堆莫名其妙东西的人
#10
up
我 在 sql 2008 中也碰到了同样的问题
我 在 sql 2008 中也碰到了同样的问题
#11
我没积分~正在努力回帖中~
#12
我也遇到这个问题。到底该怎么解决啊？
#13
你要创建全文索引的数据库右键菜单--》属性--》左侧的选择页中选择"文件"--》勾选右侧的“使用全文索引”