【讨论】建了全文索引后，速度究竟能快多少?????

[Kao2004]

在对一表建立全文索引后，感觉效果不尽人意!
此表存储的主要是文字信息，其用途也是对文本进行查询
结构如下：
id --indentity属性
text -- 文本信息
... -- 不重要的字段

总共有120万记录左右
也在试着建了各种索引，但效果均不理想!
与同是用like什么都不建速度没什么差别.

全文索引用CONTAINS检索，速度也只能有不到10%的提高，有时候比like还慢!!!晕!!!
不知大家用过后，效果如何，能提高多少！！！

[Kao2004]

自已up

[Kao2004]

再up

[lmj2003]

我也想知道，帮你顶！

[xluzhong]

疑难解答


全文检索建议
全文检索允许在 Microsoft® SQL Server™ 2000 表内对字符数据进行基于单词或短语的索引。全文检索由下面的基本组件组成：

全文索引启用了全文目录的创建和填充，它们在 SQL Server 以外维护并且由 Microsoft 搜索服务管理。


全文检索使用新的 Transact-SQL 谓词（CONTAINS、CONTAINSTABLE、FREETEXT 和 FREETEXTTABLE）来查询这些已填充的全文目录。
全文索引
如果正在对不到一百万行的表进行全文索引，那么几乎不需要进行性能优化。如果对大型 SQL Server 表（其中包含创建大型全文目录的上百万行）进行全文索引，那么这会持续进行大量的读取和写入活动，因此必须配置 SQL Server 和全文目录，以通过跨多个硬盘驱动器进行负载平衡来获得最优磁盘 I/O 性能。同时还需要考虑硬件配置、Microsoft Windows® 2000 或 Windows NT® 4.0 系统配置、SQL Server 2000 配置、全文目录和数据库文件的实际位置。

硬件考虑事项

多个 CPU：一到四个 500 MHz Xeon III 处理器。


内存：1 到 4 GB 的物理 RAM。


具有几个通道的多磁盘控制器，或具有多通道的单磁盘控制器。


磁盘 I/O 子系统：RAID0（没有容错保护的磁盘条带化）、RAID0+1 和 RAID5。
Windows 2000 或 Windows NT 4.0 系统配置的考虑事项

如果在 Windows NT Server 4.0 上安装 SQL Server，那么 pagefile.sys 文件的大小需要设置为可用物理 RAM 量的 1.5 到 2 倍。在有较大 RAM 量的 Windows 2000 Server 上安装 SQL Server 时，可以不用考虑这一条。


Pagefile.sys 文件需要放置在它们自己的驱动器（RAID0 或 RAID0+1）上，最好在单独的控制器或至少是与共享控制器分离的单独通道上。
SQL Server 配置的考虑事项

在大型表（超过一百万行）中进行完全填充后，考虑将新特性 Change Tracking 与 Update Index in Background 和 Update Index 对 Incremental Population 一起使用。有关何时使用 Change Tracking 对 Timestamp-based incremental 填充的更多信息，请参见维护全文索引。
全文索引和目录考虑事项

全文索引或填充全文目录应该在系统活动较少时进行，通常在数据库维护窗口完成。


将全文目录文件放置在它自己的磁盘控制器上，或有多个通道的单个磁盘控制器上单独的通道中。


将数据库文件放置在与全文目录文件不同的独立的磁盘控制器上，或有多个通道的单个磁盘控制器上单独的通道中。


具有四百万或两千万行的 SQL 表的全文索引可能要花费几个小时或几天来完成。考虑知识库文章 Q240867 中提供的选项："INF：如何移动、复制和备份 SQL 7.0 全文目录文件夹和文件"。
全文检索
如果正在对不到一百万行的表进行全文检索，那么几乎不需要任何性能优化。（一百万行只是常规的分界点。）如果要对超过一百万行的表进行全文检索，请考虑适当的全文检索谓词（CONTAINS 与 CONTAINSTABLE 或 FREETEXT 与 FREETEXTTABLE）以及平均行数和查询超时的考虑事项。


使用带有新的 top_n_by_rank 参数的 CONTAINSTABLE 或 FREETEXTTABLE 来限制返回的行数。top_n_by_rank 指定只返回以降序排列的前 n 个最高等级的匹配项。仅当指定了整数值 n 时应用。另外，应该考虑使用 TOP 子句来限制在 CONTAINTSTABLE 或 FREETEXTTABLE 的结果集中返回的行数。请查阅知识库文章 Q240833："FIX：通过支持 TOP 改善全文检索性能"，以获得更多信息。
如果试图通过附加的 WHERE 子句限制从全文查询得到的结果，那么 WHERE 子句是在与 SQL 表结果联接 (JOIN) 之后而非之前应用。否则，结果集会不正确，因为合格的行会从结果集中省略掉，而没有任何对客户端的提示。若要限制全文检索查询的结果，请使用 CONTAINSTABLE 或 FREETEXTTABLE 谓词中的 Top_N_Rank 参数。

如果通过 Web 或 Microsoft Internet Information 服务 (IIS) 接口使用 SQL Server 全文检索，并且正在搜索大型表（超过一百万行），那么当使用 CONTAINS 或 FREETEXT 谓词时，请考虑将 IIS 查询超时默认值增加 20 秒到 30 秒。


如果在 SQL 查询中使用多个 CONTAINS 或 FREETEXT 谓词，并发现全文检索查询性能较差，请减少 CONTAINS 或 FREETEXT 谓词的数量，或使用"*"在查询中使用所有全文索引列。
在全文查询中使用任何一个全文谓词时，例如 CONTAINS (pr_info, 'between AND king')，还可能遇到错误 7619："查询只包含忽略的单词"。单词"between"是一个忽略词或干扰词，即使带有 OR 子句，全文查询语法分析器也会将其视为一个错误。考虑将查询重新写为基于短语的查询并删除干扰词，或考虑知识库文章 Q246800 中提供的选项："INF：正确分析 FTS 查询中的引号"。还请考虑使用 Windows 2000 Server：它对索引服务的断词文件有一定增强。

什么是 RANK 以及当与 CONTAINSTABLE 和 FREETEXTTABLE 谓词一起使用时如何确定 RANK？全文 RANK 值是根据包含唯一词的行出现的频率确定的。在确定返回行的 RANK 值中发挥作用的一个因素是这个唯一词在该行的全文索引列中出现的频率。另一个因素是唯一词在表中出现的总次数（这用于规范化概率）。结果集中返回的 RANK 值是互相关联的。因此，不可能将 RANK 值解释为百分比，或将 RANK 值分组为高/中/低范围。请将 RANK 视为一种对特定查询和结果集排序的方法。
当确定是在一个全文目录中包括多个 SQL 表，还是每个全文目录一个 SQL 表时，还有一些全文索引和检索的考虑事项。当考虑大型 SQL 表的这种设计问题时，在性能和维护之间应进行权衡，而您可能希望对您的环境测试这两种选项。如果选择在一个全文目录中有多个 SQL 表，则会因运行全文检索查询时间较长而带来开销，因为增量填充会强制所有其它 SQL 表的全文索引都放在该全文目录中。如果选择每个全文目录具有一个单独的 SQL 表，并对多个 SQL 表进行全文索引，就会引起维护单独的全文目录的开销（每个服务器总共只能有 256 个全文目录）。

©1988-2000 Microsoft Corporation。保留所有权利。