通常，这类执行计划在传入参数选择能力较差时出现。换句话说，通常这种情况做一个全表扫描更容易，因为查询可能返回的行数占全表数据行数的很大比例。

　　这种方法的性能消耗如下（表中有2116400行数据，占4.1GB存储空间）：
CPU: 3,885
Reads: 506,448
Duration: 95,221
Rows: 124, 784

　　现在假定我们想执行一次搜索。为了执行优化，我们让查询返回一个小一点的结果集。例如：我们使用下面的SQL，在大结果集中查询，设置OPTIMIZE FOR为“test”，它会产生一个较小的结果集。这会引起大规模搜索，请看下面的执行计划。

declare @N nvarchar(30) set @N = N'*performance*'
select * from LargeProperty_test where contains(largeProp_value, @N) OPTION (OPTIMIZE FOR (@N = '*test*'))

　　图解2：长时间运行的"OPTIMIZE FOR"执行计划示例

　　性能消耗
CPU: 3,011
Reads: 1,112,473
Duration: 80,128
Rows: 124, 784

　　图解3：选择性运行的执行计划

　　性能消耗
CPU: 500
Reads: 96,669
Duration: 1,477
Rows: 21,120

　　与性能属性比较
CPU: 94,490
Reads: 670,105
Duration: 78,068
Rows: 21,120

　　这个测试比较了一个数据量4.1GB，拥有2116400行数据的表。如果减少行数或者减少文本内容列数，性能差异就会变得不明显。反之，如果增加文本列数和行数，性能差异会急剧上升。

　　混合方法

　　在大部分情况下，采用这些方案时，CLR存储过程实际上会降低性能，而不是提高性能。所以，选用这种方法时要谨慎，特别是因为scope creep（需求蔓延，计划跟不上变化）可能会很快变成一个问题。

　　把文本字段列按单词拆分成百分之百填充因子的簇索引会极大地提升查询速度，尽管要牺牲一定的灵活性。这种做法更适合被看作是一种附加的优化特性，或者是微软全文搜索的赠品。

　　把全文搜索结果缓存起来会比单单使用微软灵活的工具更能提高性能。尽管第一次查询会比原先慢一些，但是在此之后，所有使用相同关键字的查询都会立即返回结果，因为查询结果已经被缓存到另一个表，查询关键字就是它的簇索引。这在关键字经常重复出现的情况下会产生巨大的性能提升。

　　我不想单单依赖于SQL Server全文搜索引擎，除非可以容忍更长的响应时间。我会给性能要求高的系统推荐一个混合利用全文本搜索和另一个选项的方法。

　　为了实现快速文本搜索，我强烈推荐把15K RPM硬盘分成不同的RAID配置来存放所有组件，包括目录，临时数据库，Dump，日志，数据，非簇索引等等。如果应用混合优化方案后查询仍然太慢的话，你可能需要考虑使用固态服务器，而不是使用硬盘驱动器。