手动为主键创建索引是一种好习惯吗？

Question

我最近正在使用Entity Framework Core，但是关于主键和索引之间的关系存在一些问题。

更具体地说，我发现在包含复合主键的表中，为该键的第二个属性创建了一个索引。

You can see an example here

您能解释一下我是否应该为第一个索引手动创建另一个索引吗？还是为该第一个属性创建聚簇索引？

Answer 1

通常，即使查询仅在搜索某些列时也可以使用一组列的索引，但要限制查询必须从左到右从索引中请求列，没有空格

因此，如果为一组A，B，C，D列建立了索引，则该索引仍可用于回答在A，A and B，A and B and C上进行过滤的查询。

因此，您不需要分别为NoteID编制索引，因为辅助主键的索引（NoteID，CategoryID）可以由仅需要NoteID的查询使用。但是，它不能用于仅回答CategoryID的查询，因此将创建单独的索引

顺便说一句，在某些情况下，您可能会发现可以在where子句中提供值，这些值除了鼓励使用覆盖它们的索引外没有其他目的。例如，假设一个表在Name, Gender, Age上有一个索引，并且您希望所有20岁的人都叫史蒂文。如果可以合理地断言Steven是永远的男性，则可以WHERE Name = 'Steven' AND Gender = 'M' AND Age = 20-即使M的性别是多余的，也可以指定它使DB引擎使用该索引。省略它意味着数据库将很难确定是否使用索引

您还可以重新排列索引顺序，以帮助您的应用程序执行，并减少数据库维护的索引。如果所有查询只询问A，A + C或A + B + C，它将最好以A，C，B的顺序指定列的索引，则单个索引可以覆盖所有查询，而不必维护A + B + C和A + C的索引

Answer 2

您不需要在NoteID上创建索引，因为它是主键的第一列。通常，您希望所有外键都成为至少一个索引中的第一列。就您而言，NoteID是主键中的第一列，它充当聚集的唯一索引。