具有 Int Clustered Identity 和 NVarChar 主键的表 - 我加入哪一个？答案

【问题标题】：Table with Int Clustered Identity & NVarChar Primary Key - Which one do I join to?具有 Int Clustered Identity 和 NVarChar 主键的表 - 我加入哪一个？
【发布时间】：2014-04-30 13:57:01
【问题描述】：

我的表结构如下所示：

用户：

UserId int - clustered index & identity
UserName nvarchar - PK
Name nvarchar
Location nvarchar

用户类型加入

UserName nvarchar - PK
UserTypeId int - PK

用户类型

UserTypeId int - PK
Name nvarchar

最初我的User 表没有UserId，我使用UserName 作为主键以及标识和聚集索引列，但这导致了我的碎片问题，所以我添加了@ 987654327@ 并将其设置为聚集索引标识。

所以现在我想知道是否需要将我的连接表 UserName 列更改为 UserId，因为它是表标识，我认为它可能会提高性能，或者最好将其保留在UserName 因为它是主键？

我已经尝试在谷歌上寻找答案，但我想不出任何相关的东西。

【问题讨论】：

标签： sql sql-server primary-key clustered-index

【解决方案1】：

使用 Int 作为主键并基于该列执行所有连接将比使用 UserName 更快，尤其是因为您在该列上有一个聚集索引。

您可能应该更改所有联接以使用 UserId 并将该列设为主键。您可以在 UserName 字段上放置唯一约束，以确保该列保持唯一。

【讨论】：

【解决方案2】：

加入 UserId 可能会提高某些查询的效率，但请注意，引用 UserId 而不是 UserName 也可能会产生成本。您最终可能需要在以前不需要的地方进行连接，因为 UserName 现在仅驻留在 User 表中。此外，您可能需要额外的应用程序和数据层代码来处理 UserNames 和 UserIds 之间的映射和转换 - 假设 UserName 仍然是用户关心的内容以及您的业务逻辑所依赖的内容。我建议您在决定是否进行更改之前评估整体影响。

许多人总是将 PRIMARY KEY 约束放在其他表中的外键引用的任何键列上；其他人更喜欢“自然键”始终指定为 PRIMARY KEY。它主要归结为惯例和美学，并不一定会产生任何实际差异。我当然没有注意到 SQL Server 中的查询性能曾经受到使用 PRIMARY KEY 约束而不是 UNIQUE 约束的影响。

【讨论】：