全文索引与 %% 和聚集索引答案

【问题标题】：Full-text indexing vs %% and clustered index全文索引与 %% 和聚集索引
【发布时间】：2012-06-19 03:49:35
【问题描述】：

我有两个问题。

为什么？

每当处理 INSERT 时，聚集索引都会导致页面数据重新排序，因为新行没有附加到索引的末尾而是插入到中间

我是对的吗？为Integer 类型列选择聚集索引的任何其他原因？还是我走错方向了？

当我必须使用%...% 搜索字符串时，如下查询

Select Column1 From Table1 Where Column1 Like '%SomeVal%'

我有以下问题。

【问题讨论】：

带有 '%' 的前缀最多只能进行索引扫描。你的问题真的没有意义。与其告诉我们您认为的解决方案，不如告诉我们您要解决的实际问题。
@mitchwheat - 先生，我的查询基于包含谓词。如查询中所述。
我通常将我的索引聚集在表中最常用的外键上，这样通过该 FK 进行的查找/连接就在磁盘上的同一页面中（应该更快）。此外，%...% 相当昂贵，具体取决于您预期的记录数量。我会尽可能避免这些，但 FTS 是另一种蠕虫。如上所述，更多细节会有所帮助。

【解决方案1】：

是的，SQL Server（以及一般的计算机）在查看数字列表时比查看文本列表更快。这意味着搜索 WHERE ID = 3 的记录通常比 WHERE FirstName = 'BOB' 更快。如果您的系统已准备好跟踪其中一个或另一个，这将非常有用，例如当用户单击产品时，您可以选择存储 ProductID 或 ProductName，ProductID 会拉得更快。但是，如果 WHERE 子句中唯一的列是一个文本文件，就像您总是按标题查找电影一样，那么最好将聚集索引放在该列上。作为一般规则，我有一个带有聚集索引的整数 ID 字段，然后在另一个字段上放置一个非聚集索引，但这确实取决于具体情况。
FTS 是基于单词的，而通配符 (%) 是基于模式的，因此如果您需要在文本字段中搜索“Patricia”，FTS 可能是您的最佳选择，但如果您需要搜索“Pat%”来寻找“Patrick”或“Pattie”或“Patricia”，FTS 将无法正常工作。我希望这是有道理的。在 StackOverflow 或 google 中搜索“fts vs like”，你会得到一些关于这个问题的讨论。

【讨论】：