我应该在聚集索引表上添加一个非聚集索引，基于这个where子句和连接吗？

我有一个父表和一个子表。我应该在聚集索引表上添加一个非聚集索引，基于这个where子句和连接吗？

父表具有聚集索引作为主键和增量值（ParentID）。子表还具有聚集索引作为具有增量值的主键（ChildID）

主键Parent.parentID与作为外键的child.parentID有关。

我根据以下查询加入这两个表。

Select .... 
Join on parent.parentID = child.parentID 
where parent.personalNumber = 197608134356 <-- varchar

现在，parent.personalNumber我应该

添加非聚集索引，因为它是在where子句中？
在外键child.parentiD上添加非聚集索引以加速连接？

这将意味着我把非聚簇索引放在聚簇索引表上。

随着时间的推移，我预计父母和孩子都会有很多行。将会有插入和选择。没有更新或删除

感谢 /s的

来源

2013-11-26 user2994221

我的建议是为'personalNumber'添加一个索引。那么'child.parentID'取决于优化器使用哪种类型的连接。通常，在'child.parentID'上添加索引是个好主意。 –

我肯定会在'child.ParentID'上添加非聚集索引来帮助JOIN。是否在父母的NC指数。PersonalNumber'的帮助取决于：（a）“PersonalNumber”的选择性（具有给定的值，原始行将被检索多少％）？（b）在“SELECT”子句中具有什么样的列（如果在任何地方使用'SELECT *'，那么NC索引的用处就会大大减少） –

您可以对表只能有一个聚集索引，并且你已经有一台的ParentId父表，一个用于childID的子表上，两者都增加值至极是好的，主键也是好的（不是强制性的，你可以选择在其他列上使用聚簇索引，在你的pk上使用非聚簇索引）。

您的设计看起来不错。您必须在搜索列（parent.personalNumber和其他人，如果有）和外键上添加非聚集索引，这通常会有所帮助。

来源

2013-11-26 19:08:53 ARA

使用聚集索引进行PK，除非您有一个令人信服的理由不要。

也就是说携手仍然可以使用群集复合PK儿童
检查执行计划 - 我会感到非常惊讶，如果是聚簇索引是不使用加入

在personalNumber的指数应援哪里

来源

2013-11-26 19:51:21 Paparazzi

一个令人信服的理由是主键不会“递增”，这并不是那么罕见。插入会非常严重地破坏集群 – ARA

@Alain_Deloin但是它仍然会严重地破坏非集群唯一索引。授予一个严重分散的非群集可以更容易管理，但我仍然倾向于在群集上受到打击。但有一点要说。 – Paparazzi

你是完全正确的，但“有时”不是你设计数据库;） – ARA

如果您正在设计高性能，有许多并发客户端，所有客户端同时插入到您的表中 - 您不应该有一个基于也是标识列的PK的聚簇索引。有关说明，请参阅此article。这样做会在表格中创建一个热点，从而对性能产生不利影响。

几乎总是有一个更合适的列来将聚簇索引基于标识列作为PK的表中。

来源

2013-11-27 06:33:42 dav1dsm1th

我应该在聚集索引表上添加一个非聚集索引，基于这个where子句和连接吗？

回答

相关问题