sql-server - MS-SQL Server 2000慢速全文本索引

Question

我们在633,569条记录的相当大的表上拥有全文索引。在运行一堆删除/插入记录的DTS程序包后，每天晚上作为维护计划的一部分，从头开始重建索引。删除大块数据，然后将其插入（以进行更新和插入），因此无法建立增量索引。将软件包更改为仅在必要时删除是不可能的，因为这是一个最终将被替换的旧应用程序。

FTI包括两列-一列varchar（50）不为null，而varchar（255）为null。

在主键列上有一个聚集索引，它只是一个标识列。在整数列和上面提到的varchar（50）列上也有组合索引。出于性能原因添加了后一个索引。

问题在于重新索引编制非常缓慢-大约8个小时。

该服务器相当强大（双处理器，RAM为4gb），并且所有工作都超出了重新索引的范围。

关于如何加快速度的任何提示？

更新

我们的客户可以访问sql框。原来，他们在全文索引的一部分表上启用了更改跟踪。我们关闭了此功能，整个人群花费了不到3个小时。仍然不是很好，但是比8好。

更新2

FTI再次需要约8个小时来填充。

Answer 1

SQL Server的索引速度很慢，主要是因为其异步数据提取方案。


在“更新”中使用更改跟踪
在后台索引”选项。


改善全文索引性能的最简单方法是将更改跟踪与“后台更新索引”选项一起使用。对表进行索引时（FTI，例如“标准” SQL索引，在每个表上工作） ，您可以指定全部填充，增量填充或更改跟踪。选择完全填充时，将对要全文索引的表中的每一行进行提取并建立索引。这是一个两步过程。

首先，您（或企业管理器）运行此系统存储过程：

sp_fulltext_getdata CatalogID, object_id

将所有时间戳记和PK值的所有结果集返回给MSSearch之后，MSSearch将发出另一个sp_fulltext_getdata，但这一次，表中的每一行一次。因此，如果数据库中有5000万行，则此过程将发行5000万次。

另一方面，如果您使用增量填充，则MSSearch将发出首字母缩写：

sp_fulltext_getdata CatalogID, object_id

为您要全文索引的表中的每一行。因此，如果您的数据库中有5000万行，则该语句也将发出5000万次。为什么？因为即使人口增加，MSSearch也必须准确找出更改，更新和删除了哪些行。增量填充的另一个问题是，即使对您不是全文索引的列进行了更改，它们也会对行进行索引或重新索引。

尽管增量填充通常比完整填充快，但是您可以看到，对于大表而言，任一个都将很耗时。

我建议您启用后台或预定更新的更改跟踪。如果这样做，您会看到MSSearch将首先发出另一个：

sp_fulltext_getdata CatalogID, object_id

对于启用了更改跟踪的表中的每一行，然后，对于具有您要全文索引的列并在初始全部填充后被修改的每一行，行信息将被写入（在您索引）到sysfulltextnotify表。然后，MSSearch将仅对该表中出现的行发出以下命令，然后将其从sysfulltextnotify表中删除。


考虑使用单独的版本
服务器


在编制索引时对表进行大量更新可能会导致锁定问题，因此，如果您可以使用定期过期的目录和有时不可用的MSSearch引擎，请考虑使用单独的构建服务器。为此，请确保索引服务器具有要全文索引的表的副本并导出目录。显然，如果需要对目录进行实时或近实时更新，这不是一个好的解决方案


当人口为
跑步


当运行人口时，请勿运行Profiler，并尽可能限制其他数据库活动。 Profiler消耗大量资源。


增加用于的线程数
索引过程


增加正在为索引过程运行的线程数。默认值只有五个，在四倍或八次方上，您可以将其提高到更高的值。但是，如果MSSearch会从SQL Server中获取过多数据，则它会自行限制，因此请避免在单处理器或双处理器系统上执行此操作。


停止任何防病毒或打开
文件代理备份软件。


如果这不可能，请尝试阻止它们扫描SQL FTI正在使用的临时目录和目录目录


放置目录，临时目录和
页面文件在它们自己的控制器上


如果可以进行投资，请将目录放置在其自己的控制器上，最好放置在RAID-1阵列上。将temp目录放置在RAID-1阵列上。同样，请考虑使用自己的控制器将页面文件放在其自己的RAID-1阵列上。


考虑创建辅助数据
临时数据库的文件-每个CPU 1个/
核心。