在SQL Server 2005数据库中，我有很多像这样的Products表
的表ProductID (PK)
ProductCategoryID (IX)
Description
Price
ExpiryDate
BreakableYN
...其中有一个主键，一个外键，然后是一堆其他字段。这种类型的表的另一个特征是许多查询仅使用2个ID字段（ProductID，ProductCategoryID），例如， Employees JOIN EmployeeProductJoin JOIN Products JOIN ProductCategories JOIN ProductDepartments。
如果ProductID和ProductCategoryID已经编入索引，是否值得为ProductID，ProductCategoryID添加另一个索引？
我知道我似乎在问是否添加覆盖索引会有所帮助，但我真正要求的是如果覆盖索引中的字段已经单独编入索引，那么覆盖索引是否会有所帮助
这些定义表并不大，所以我并不担心会给INSERT等增加额外的时间。
答案 0 :(得分：1)
是的，可能。覆盖索引的要点是，索引可以单独由索引提供，而无需访问该表。因此，您不仅要包括要搜索的字段，还要包括要返回的字段，查询优化器可以完全避免访问该表。
你可能并不真的是指“覆盖索引”，但是......
答案 1 :(得分：1)
主键是否已群集？如果是，则添加新索引将不会做任何事情，因为ProductCategoryID索引已经包含ProductID值，因此它有效地“覆盖”了两列。
答案 2 :(得分：0)
只有查询计划（包含和不包含额外索引，以及包含实际数量和数据类型的表）可以告诉您确定额外索引是否有帮助;这一切都是为了帮助查询优化器找到更智能的计划，但是到目前为止你只能提供帮助， 可以想象它可能无法找到你想要的计划（它只是一个启发式“让我尝试优化“引擎，毕竟”。这就是为什么查看查询计划非常重要（并且您需要拥有真实的数据，因为这通常会影响启发式！）。
答案 3 :(得分：0)
我绝对可以提供帮助，特别是如果您的描述很大。很容易进行基准测试并亲眼看看。这个新索引可能比群集索引小得多。 但是如果您有非常重要的查询，那么您只想拥有这个狭窄的索引，无论如何都需要加速。
答案 4 :(得分：0)
是的，它可以以一种特定的方式提供帮助。覆盖索引的想法是它有一些您在查询中使用的冗余字段。如果索引可以满足查询的数据要求而不需要查询基础表，则可以通过从索引获取数据来节省I / O.
如上所示，如果您有两个索引，则DBMS必须访问该表以及解析两个索引搜索。
如果您的查询结果广泛分散在表中但属于索引，则可能会在大型查询中节省大量I / O.通过这种方式，覆盖索引也可以用作表上的一种“第二聚簇索引”。
答案 5 :(得分：0)
简而言之，是的，它将提高查询性能。
使用覆盖索引，查询中所需的所有列都存在于索引数据结构中。这意味着SQL服务器只需要查询单个索引，以便为查询提供结果。
当你有一个多列的场景时，它们是单独索引的，为了服务这个查询，SQL Server很可能不得不执行多个索引的搜索/扫描而不仅仅是一个索引。这当然可能会产生更多的I / O活动。
有意义吗？