Primary key和unique Key constraint之间有什么区别？
有什么用？
答案 0 :(得分：12)
两者都用于表示candidate keys表。
您只能为表创建一个主键，因此如果您有多个候选项，则只需选择一个。
可以在外键约束中使用。在SQL Server中，主键列不能为空。 Unique Key约束中使用的列可以是。
默认情况下，在SQL Server中，如果主键在堆上创建，则主键将成为聚簇索引，但它并不强制要求PK和聚簇索引应该相同。
答案 1 :(得分：7)
主键是用于标识相关行的键。除此之外它可能还有一些含义（如果已经存在一段可以服务的“真实”数据）或者它可能纯粹是一个实现工件（大多数IDENTITY列，并且在其他数据库上等效的自动递增值系统）。
唯一键是更一般的情况，其中键不能具有重复值。在大多数情况下，人们不能拥有与同一管辖区相同的社会安全号码（国际案例可能不同）。因此，如果我们存储社会安全号码，那么我们希望将它们建模为唯一的，因为它们匹配现有数字的任何情况都显然是错误的。用户名通常也必须是唯一的，所以这是另一种情况。外部标识符（由另一个系统，标准或协议使用的标识符）往往也是唯一的，例如只有一种语言具有给定的ISO 639代码，因此如果我们存储ISO 639代码，我们会将其建模为唯一。
这种独特性也可以跨越多个列。例如，在大多数分层分类系统（例如文件夹结构）中，没有项目可以具有相同的父项和相同的名称，尽管可能存在具有相同父项和不同名称的其他项，以及具有相同名称和不同名称的其他项父母。这种多列功能也存在于主键上。
表格也可能有多个唯一键。例如。用户可能同时拥有ID号和用户名，两者都需要是唯一的。
因此，任何不可为空的唯一键都可以作为主键。有时，来自建模的固有数据的主键被称为“自然主键”，因为它们是数据的“自然”部分，而不仅仅是实现假象。关于使用哪种方法的决定取决于以下几点：
规格变更的可能性。如果我们将社会安全号码建模为唯一，然后必须适应允许多个司法管辖区，其中两个或更多使用类似的足够编号系统以允许冲突，我们可能只需要删除唯一性约束（其他更改可能< / em>需要）。如果它是我们的主键，我们现在还需要使用新的主键，并将任何使用该主键的表更改为关系的一部分，以及任何加入它的查询。
查询速度。关键效率可能很重要，因为它们在许多WHERE子句中使用，并且（更常见地）在许多JOIN中使用。特别是JOINS，查找速度至关重要。影响将取决于实现细节，不同的数据库根据它们处理不同数据类型的方式而有所不同（从性能角度来看，在Postgres中使用大块文本作为主键，我可以指定使用hash join，但是我在SQLServer中会非常犹豫[编辑：对于“大”我想的可能是用户名的大小，而不是整个Norse Eddas的大小！）。
密钥的频率是唯一有趣的数据。例如，使用语言表和该语言的注释表，通常我在处理注释表时想要加入语言表的唯一原因是获取语言代码或限制对具有特定语言代码的人的查询。关于该语言的其他信息可能更少使用。在这种情况下，加入代码的效率可能低于加入IDENTITY列中的数字id集，将代码作为主键 - 因此存储在外键列中的内容评论表 - 根本不需要任何JOIN，效率可观。虽然我想从相关表格中获得更多信息，但更常见的是，使JOIN更有效率更为重要。
答案 2 :(得分：5)
主键：
主键只是唯一标识表中的每一行。
主键不允许重复值，也不允许NULL。
默认情况下，主键是聚簇索引。
一个表只能有一个主键。
唯一键：
唯一键只是唯一标识表中的每一行。
唯一键不允许重复值，但允许（最多一个）NULL。
默认情况下，唯一键是非聚集索引。
这是一个完整的水果链接，用于了解 主键 Database Keys. 请记住，表中只有一个聚簇索引[谈论SQL Server 2005]。 现在，如果我们想要添加另一个唯一列，那么我们将使用 唯一键 列，因为 可以添加多个唯一键列。
答案 3 :(得分：3)
主键只是任何一个候选键。原则上，主键与任何其他候选键没有区别，因为关系模型中的所有键都相同。
然而，SQL有两种不同的语法来实现候选键：PRIMARY KEY约束和UNIQUE约束（当然，在非可空列上）。在实践中，它们完全相同，除了基本无用的限制，PRIMARY KEY每个表只能使用一次，而UNIQUE约束可以多次使用。因此PRIMARY KEY约束没有基本的“使用”。它是多余的，很容易被忽略或完全从语言中删除。然而，许多人发现将每个表中的一个特定密钥单独输出具有特殊意义是很方便的。有一个非常广泛观察到的约定，使用PRIMARY KEY指定的密钥用于外键引用，尽管这完全是可选的。
答案 4 :(得分：1)
简短版本：
因此，区分一个唯一键作为“主键”只是一种实现方便（但很重要）。