具有聚集唯一索引的不可空列。为什么需要主键？
在Server中，我有一个非空列，其中有一个唯一聚集索引。如果我将此列设置为主键，则会自动创建完全相同的索引，并且该列被识别为主键。
我理解抽象/语义上的差异。
(主键标识实体，而具有此索引的任何其他列则不能。
例如，一个人可以有一个电子邮件字段是唯一的，非空的.但可以改变)
但困扰我的是，当涉及到DB引擎本身时，本身的实际差异，。
如果我只创建一个Id列，使其非空，为它创建一个唯一的聚集索引，使其身份增量，但没有主键约束，会发生什么？
主键约束在什么场景中起作用？
(在问这个问题之前，我看过许多相关的问题，但我看到的所有答案最后都得到了抽象的/理论的解释)。
回答 2
Stack Overflow用户
发布于 2013-03-31 15:59:34
没有什么是真正不同的。您可以指定PRIMARY KEY来传递您的意图，而不是让引擎执行任何不同的操作。在构建查询计划时，优化器仍将对其所有属性使用唯一性，并且仍然将对其所有属性使用聚集索引，无论技术上是否将其创建为PRIMARY KEY。创建FOREIGN KEY时，仍然可以引用指定为唯一(群集与否)的列。区别仅在于元数据(sys.indexes.is_primary_key)和SSMS对您的表示(哦，以及您可以在NULLable列上创建唯一的聚集索引，但不能在该列上创建PRIMARY KEY )。
实际上，在许多情况下，您希望将聚集索引与PRIMARY KEY完全分离。例如，如果您有一个PK是GUID的表，并且通常对表运行日期范围查询，那么最好是让PK非聚集，并在自然增加的列( datetime列)上有一个聚集索引--这两者都是为了最大限度地减少大量插入活动上的页面分裂，也是最好地帮助日期范围查询。对于查找单个GUID，非聚集索引将是非常好的。(我想提到这一点，因为很多人认为主键必须聚集在一起。不对。)
同样有趣的是，如果您创建一个PRIMARY KEY约束，然后使用DROP_EXISTING创建同名的惟一聚集索引，则is_primary_key列仍然是1，对象资源管理器仍将在Keys下显示索引名。
Stack Overflow用户
发布于 2013-03-31 16:03:09
这里有一个场景--很多到数据映射框架的代码都会查看数据库元数据(主键、外键等)，以确定代码是如何执行的。例如，Hibernate requires a primary key。
典型的场景可能是为更新生成一个where子句。
https://stackoverflow.com/questions/15731276
复制相似问题
腾讯云开发者
