如果我创建的索引是第二个索引开头的部分键，那么当搜索条件与更简单的索引匹配时，服务器能够以多快（如果有的话）检索更简单的索引的结果？
例如，如果我有一个非聚集索引(TransactionDate, ClientID, State) 并且我的搜索条件只是TransactionDate，那么通过创建andClientID的第二个索引可以实现哪些搜索性能提升？该表具有非常典型的数据分布。大约有 1200 万行，100 个日期，每天约有 160,000 条记录，分布在 500 个客户中。TransactionDateClientID
不考虑索引维护 ( inserts, updates, deletes) 和磁盘空间使用情况。sql server 如何实现和利用索引的低级细节将不胜感激。
由于您明确表示您不关心与维护多个索引相关的开销，因此答案是肯定的。如果您只搜索第一个键，那么对于性能和速度而言，只有一个键列的窄索引比具有多个列的窄索引要好。
如果您只搜索第二、第三键之一。然后将它放在它自己的索引中会更好，因为它可以避免索引扫描，因为只有索引中列出的第一列可以用于直接查找。
仅考虑搜索速度的最佳做法是将索引分成两个（甚至三个），当定期搜索单个术语时，每列都有自己的索引。如果边缘情况使用多个谓词，引擎仍然可以与多个索引相交。
注意：如果你经常搜索两个谓词；那么在这些搜索中，两者的复合索引更好，因为它不必相交。
在实际使用中（即 OLTP 与 OLAP 或磁盘空间考虑因素可能另有规定），最佳方法可能会有所不同 - 但同样，您说您并不关心这一点。
请注意，您在现实世界中对任何性能提升/速度提升的感知可能是绝对无法察觉的；但在某些情况下，任何一点点都有帮助。 看看这个 Microsoft 的 SQL 索引性能检查表。
附加更新：
这是 Brad McGehee 关于这个主题的一篇非常好的文章
http://www.sql-server-performance.com/2007/composite-indexes/
例如，如果我有一个非聚集索引（TransactionDate、ClientID、State），并且我的搜索条件只有 TransactionDate 和 ClientID，那么通过创建 TransactionDate 和 ClientID 的第二个索引可以获得什么搜索性能提升？
一般没有。
索引(TransactionDate, ClientID)会稍微窄一些（因为它不需要 store State），但它仍然具有相同数量的叶子（以及指向表行的指针）。因此，虽然它将更紧密地集群节点，但优势可能很小。
维护额外索引的开销几乎肯定会超过这个好处。并且通过维护，我不仅仅指修改，我还指缓存，因此即使附加索引在理论上可能更好，您也可能会从单个索引中看到更好的实际搜索性能。
顺便说一句，如果您的表恰好是集群的，这将使二级索引更加昂贵且不太理想。
如果您还不熟悉该主题，我强烈建议您查看SQL 索引剖析。无论如何，我建议您在得出自己的结论之前测量实际数据量。