已声明为NOT NULL UNIQUE CLUSTERED INDEX的列设为PRIMARY KEY会有性能变化吗？

好问题！这个点其实很多人都会混淆，我来给你掰扯清楚：

性能层面：几乎无变化 #

从底层存储和执行效率来说，不会有任何实质性的性能差异。原因很简单：在SQL Server里（毕竟你提到了CLUSTERED INDEX，这是SQL Server的术语），主键默认就是绑定了NOT NULL UNIQUE约束的聚集索引（除非你手动指定非聚集主键）。你现在已经有了一个NOT NULL UNIQUE的聚集索引，它的存储结构（B树）和主键对应的聚集索引完全一样。

• 读写查询的执行计划不会变，开销和之前完全一致
• 数据库优化器会把这两种索引视为等价的唯一性、非空性约束，不会有逻辑判断上的性能损耗

功能与语义层面：有这些变化 #

虽然性能没影响，但在约束语义和工具适配上会有明显区别：

• 语义更清晰：主键是明确的“表行唯一标识符”，能让其他开发者一眼就知道这列是表的核心标识，而唯一索引只是保证列值不重复，语义上弱一些。
• 外键关联的标准性：虽然外键可以引用唯一约束列，但主键是外键关联的标准目标，很多团队的规范里会要求外键必须指向主键，这样更符合数据库设计的最佳实践。
• 工具适配更好：很多ORM框架（比如Entity Framework）、数据建模工具会自动识别主键作为实体的唯一标识，改成主键后你不用额外配置就能让这些工具正常工作。
• 约束数量限制：一个表只能有一个主键，但可以有多个NOT NULL UNIQUE的非聚集索引（聚集索引本身就只能有一个），所以设置主键后，这列就占用了表的唯一主键名额。

操作时的注意事项 #

• 如果你是用ALTER TABLE [表名] ADD PRIMARY KEY CLUSTERED ([列名])来修改的，数据库不会重建这个聚集索引——它只是给已有的唯一聚集索引加上主键约束的标记，所以不会有锁表或者索引重建的开销。
• 确认这列确实适合作为主键：主键的语义是“业务上的唯一行标识”，不要为了改而改，只有当这列确实承担了唯一标识行的角色时，改成主键才合理。

内容的提问来源于stack exchange，提问作者DRastislav