在正常情况下，创建一个作为现有索引开头的部分键的索引有什么显著的优点吗

Question

如果我创建的索引是第二个索引开头的部分关键字，当搜索条件与较简单的索引匹配时，服务器检索较简单索引的结果的速度会有多快(如果有的话)？

例如，如果我有一个非聚集索引(TransactionDate, ClientID, State)，而我的搜索条件只有TransactionDate和ClientID，那么通过创建TransactionDate和ClientID的第二个索引，我会获得什么搜索性能提升呢？该表具有非常典型的数据分布。大约有1200万行，100个日期，每天大约16万条记录，分布在500个客户端上。

不考虑索引维护(inserts、updates、deletes)和磁盘空间使用。如果您能详细了解sql server如何实现和利用索引，我们将不胜感激。

Answer 1

由于您明确表示您并不关心与维护多个索引相关的开销，因此答案是肯定的。为了提高性能和速度，如果只搜索第一个键，那么只有一个键列的窄索引比有多个键列的窄索引要好。

如果您只搜索第二个、第三个密钥中的一个。然后把它放在它自己的索引中会更好，因为它可以避免索引扫描，因为只有索引中列出的第一列可以用于直接查找。

仅考虑搜索速度的最佳实践是将索引拆分为两个(甚至三个)，当定期搜索单个术语时，每一列都有自己的索引。如果边缘情况使用多个谓词，引擎仍然可以与多个索引相交。

注意:如果您经常搜索两个谓词；那么在这些搜索中，两个谓词的复合索引更好，因为它不必相交。

在实际使用中(例如，OLTP与OLAP或磁盘空间考虑因素可能不同)，最好的方法可能会有所不同-但同样，您说您并不关心这一点。

请注意，您在现实世界中对任何性能增益/速度增益的感知可能是绝对不可察觉的；但在某些情况下，任何一点都是有帮助的。Take a glance at this Microsoft's SQL Index Performance Checklist。

附加更新：

这是Brad McGehee写的一篇很好的文章。

http://www.sql-server-performance.com/2007/composite-indexes/

Answer 2

例如，如果我有一个非聚集索引( TransactionDate，ClientID，

)，而我的搜索条件只有TransactionDate和ClientID，那么通过创建TransactionDate和ClientID的第二个索引，我将获得什么搜索性能增益？

一般都没有。

索引(TransactionDate, ClientID)会稍微窄一些(因为它不需要存储State)，但是它仍然有相同数量的叶子(以及指向表行的指针)。因此，虽然它会将节点群集得更紧密，但优势可能很小。

维护一个额外索引的开销几乎肯定会超过这个好处。我所说的维护不仅仅是指修改，我还指缓存，因此您可能会从单个索引中看到更好的实际搜索性能，即使额外的索引在理论上可能更好。

顺便说一句，如果您的表恰好是集群的，这将使辅助索引更昂贵，更不可取。

如果你还不熟悉这个话题，我强烈建议你看看Anatomy of an SQL Index。无论如何，在得出您自己的结论之前，我建议在实际数据量上测量。