使用非聚集索引上的包含列的原因是为了避免对聚集数据进行“书签查找”。问题是，如果SQL Server _理论上可以_使用特定的非聚集索引，但Optimiser估计将存在“太多”书签查找，则将忽略该索引。但是，如果可以直接从索引访问所有选定的列，则无需进行书签查找。
对于您而言，通过“聚集索引查找”访问数据的事实非常有前途。很难提高其性能。包括所有选定列的非聚集索引可能会 稍微
快一些，但这仅仅是因为原始数据要少一些。（ 但不要忘记增加插入/更新时间的代价 。）
但是，您应该检查详细信息…
- 如果您使用的是复合键，而查找实际上仅在键的开头，那么您可能不会很幸运。您可能会发现搜索范围仅缩小到500,000行，然后根据其他条件进行搜索。在这种情况下，请尝试使用一些非聚集索引。
- 聚集索引查找本身可能很好；但是如果由于某些其他方面无法有效地返回太多行而在查询中执行了100,000次，那么通过提高聚集索引查找的性能就不会有太大收获。
最后，阐述戴维克的评论：“成本是相对的”。仅仅因为群集是查询成本的77％，并不意味着存在问题。可以编写一个简单的1表查询，该查询返回一个单行，并且聚集索引查找成本为100％。（但是，当然，作为唯一完成的“工作”，这
将是 工作的100％…而即时的100％仍是 即时的 。 所以：“不用担心；要开心！”
