（6）增量填充
只调整自上次填充后添加、删除或修改的行的索引项。该功能要求索引表包含timestamp数据类型的列。如果表不包含timestamp列，则只能执行完全填充或更改跟踪填充。对不包含timestamp列的表请求进行增量填充将导致完全填充操作。
如果为一个此前未与目录相关联的表定义新的全文索引，则对目录的下一个增量填充请求将为该表生成所有的项。如果自上次填充后更改了表的任何元数据，增量填充请求将作为完全填充执行。这包括更改列、索引或全文索引定义。
4.9.3优化的细节
调理SQL Server全文索引是一件细致的事情。需要配置SQL Server和全文目录，通过跨多个硬盘驱动器进行负载平衡来获得最优的磁盘I/O性能，还要做好硬件配置、服务器系统配置等。下面列出一些可以帮助优化的方案，供读者参考。
（1）硬件优化
服务器有多个CPU，内存越大越好，一般是4GB左右。使用具有多个通道的多磁盘控制器，或具有多通道的单磁盘控制器。磁盘I/O子系统使用RAID0，RAID0+1或RAID5。
（2）系统配置
增大pagefile.sys文件的大小，将其设置为物理内存的2倍。同时pagefile.sys文件需要防止在它们自己的驱动器上，最好在单独的控制器或至少是与共享控制器分离的单独通道上。
（3）SQL Server的配置
在大型表中进行完全填充以后，考虑将变更跟踪和后台更新索引与增量索引一起使用。
（4）全文索引和目录的设置
全文索引或全文目录填充应该在系统活动较少的时候进行，通常在数据库维护窗口完成。
将全文目录文件放置在它自己的磁盘控制器上，或具有多个通道的单个磁盘控制器的单独通道中。将数据库文件放置在与全文目录文件不同的独立的磁盘控制器上，或有多个通道的单个磁盘控制器的单独通道中。
（5）应用程序优化
应用程序的优化，并不是三言两语可以说清楚的。但其思想是：在开发的过程中实现优化，而不是开发完成之后再专门去做优化。美国的一个软件工程师说“性能即过程”，这是完全正确的。具体在开发的时候，要注意：少做字符串联接，注意关闭数据库联接，减少网络往返等。在数据量特别大的时候，要根据实际需要去提取用户要求的结果，而不是一次显示出所有的结果。此外，应用程序的缓存也是极为重要的，可以显着改善用户体验。可以异步操作的尽量异步操作。
4.9.4索引优化
1.索引优化的概念
索引优化是数据库优化的一部分。可以通过分析SQL语句执行和分析系统性能的方法来实施。但是，这里有一种专门用于实现索引优化的工具——索引优化向导。
使用索引优化向导可以为SQL Server2000数据库选择和创建优化的索引集和统计信息集，而不需要深入了解SQL Server的数据库结构、工作负荷或内部原理。
为了生成适用的优化索引集建议，该向导需要工作负荷。工作负荷包含一个保存在文件或表中的SQL脚本或SQL事件探查器跟踪，其中有SQL批处理或远程过程调用（RPC）事件类，以及EventClass和Text数据列。
2.索引优化向导的作用
索引优化向导可以做的工作有以下几方面。
①根据给定的工作负荷，通过使用查询优化器分析该工作负荷中的查询，为数据库推荐最佳索引组合。
②分析所建议的更改将会产生的影响，包括索引的使用，查询在表之间的分布，以及查询在工作负荷中的性能。
③推荐为执行一个小型的问题查询集而对数据库进行优化的方法。
向导生成的建议由SQL语句构成，执行这些语句可以创建更有效的新索引，如果需要，还可以除去无效的现有索引。建议在支持索引视图的平台上使用索引视图。索引优化向导提出建议后，该建议可以：立即执行；或安排在以后通过创建执行SQL脚本的SQL Server作业执行；或保存到SQL脚本中，用户在将来某个时候或在另一个服务器上手工执行。
注意：对于当前选定的数据库中不存在的跨数据库查询所引用的表、系统表，以及PRIMARY KEY约束和唯一索引，索引优化向导不推荐索引。
3.索引优化向导的注意事项
索引优化向导的主要注意事项有以下几个方面。
索引优化向导在一个工作负荷中最多可以包含32767个可优化查询。负荷中超出此数目的查询将不被考虑。此外，带有被引用的标识符的查询将不予优化。
索引优化向导通过数据采样搜集统计信息。因此，如果连续在同一个工作负荷上执行该向导，则每次推荐的索引可能各不相同，执行推荐索引后的改进效果也可能各不相同。
索引优化向导不能用于在SQL Server6.5版或更早版本的数据库上选择或创建索引和统计信息。
当把SQL脚本保存到可用空间不足的磁盘上时，索引优化向导并不给出错误。
在分析过程中，索引优化向导会消耗相当多的CPU及内存资源。最好在生产服务器的测试版上执行优化，而不要在生产服务器上执行。此外，最好在另一台计算机上而非运行SQL Server实例的计算机上运行该向导。
在被采样的表中数据不足，及建议的索引对现有索引的查询性能预计带来的改进不够充分的情况下，索引优化向导可能不会提供索引建议。
工作负荷中的查询在唤醒调用索引优化向导的用户的安全上下文中进行分析。该用户必须是固定服务器角色sysadmin的成员。
为减少索引优化向导的执行时间，要注意以下三点：
确保在“选择服务器和数据库”对话框中未选择“进行彻底分析”。进行彻底分析将会使索引优化向导对查询进行详尽的分析，导致执行时间延长。但选择此选项可以使所优化的工作负荷的性能得到更大的全面提高。
只对数据库中表的子集进行优化。
减小工作负荷文件的尺寸。
如果选定了“保留所有现有索引”选项，则索引优化向导不建议除去任何索引，而是在适当的时候只建议新索引。如果清除此选项，则工作负荷的性能会全面提高。此外，索引优化向导也不会推荐除去对PRIMARY KEY约束的索引或UNIQUE索引。但可能会除去或替换不是唯一或不是当前在PRIMARY KEY约束上创建的索引。
索引优化向导在最终建议内包括所有索引提示或查询提示，即使索引对于表并非是最佳的。所有指定为提示的索引始终是最终建议的一部分，但提示会妨碍索引优化向导选择更好的执行计划，因此在分析工作负荷之前应考虑从查询中删除所有索引提示。
SQL查询分析器中的索引分析使得可以对单个查询或成批查询进行分析，并为用于支持给定查询或成批查询的优化索引集生成建议。只有sysadmin固定服务器角色成员才可以使用SQL查询分析器进行索引分析。
若要推迟生成索引优化向导所建议的索引，可使用SQL查询分析器保存建议的SQL脚本。将SQL脚本保存到文件中，可以使索引分析推荐的Transact-SQL语句在执行前得到检查，从而可以在执行前对SQL脚本进行编辑（例如，可以更改所生成的索引的名称）。
4.启动索引优化向导
启动索引优化向导的步骤如下所示。
展开服务器组，再展开要在其中创建索引的服务器（如LOCAL）。
在“工具”菜单上选择“向导”命令。弹出“选择向导”对话框。在“管理”文件夹中选择“索引优化向导”。
在弹出的“索引优化向导”对话框中，依次完成各步骤的设置。
小结
本章介绍了SQL Server全文搜索的原理和相关技术，讲解了基于数据库的全文搜索的通用实现方案。读者可以依靠这种技术来解决很多全文搜索的问题。本章讲解得比较细致，这是因为考虑到所有数据库的全文搜索的实现大同小异，所以在这里详细介绍，给读者以全面具体的指引，希望使读者从整体上把握全文搜索技术。同时，在后面讲解Oracle和MySQL的全文搜索技术时，笔者会讲解核心知识，不会逐步分析其原理。当然，这也是考虑到不希望把书写成厚厚的一本。
思考与练习
1.SQL Server的全文搜索是如何实现的？
2.改良Web应用的全文搜索引擎，使其成为一个可复用的商业软件模块。
3.SQL Server进行全文搜索的时候，会过滤掉干扰词。干扰词的列表存储在MSSQLFTDATASQLServerConfig目录下面。比如，简体中文的干扰词库是noise.chs。试着修改这些文件，可以微调搜索引擎的性能。
