数据库表只能有一个主键而不是两个或更多..为什么会这样？
答案 0 :(得分：7)
主要原因是因为这是主键的定义。一个表可以有多个唯一键，用于标识每一行，但只能标识一个主键。
在MySQL等数据库中，主键也是聚簇索引。这提供了一个更直接的原因。数据根据聚簇索引在页面上排序。一张表只能有一个排序顺序。
答案 1 :(得分：0)
在关系数据库模型中，主键是用于保证唯一访问的标识属性。为表指定主键时，数据库引擎通过为主键列创建唯一索引来强制数据唯一。
MS Technet的进一步阅读： https://technet.microsoft.com/en-us/library/ms191236(v=sql.105).aspx
答案 2 :(得分：0)
一个（关系）表＆＃34;超级键＆＃34;是每组在表中具有唯一子行的列集。 （请注意，超级密钥的每个超集也是一个超级密钥。）（简单的SQL KEY声明了什么，以及那些超集。）不包含较小超级密钥的超级密钥是＆＃34;候选密钥＆＃34;。规范化和其他关系理论关注候选键并且不关心主键。就查询，更新和约束的含义而言，没有必要或基础来选择一个候选密钥并将其称为“＃34; primary＆＃34; （和其他人＃34;替代＆＃34;）。它只是从关系模型早期的关系前系统延续下来的传统，当时它并没有被理解为是不必要的。
索引的目的也是不必要的（必须具有性能，另一个重要的可观察表达式）。
然后，因为有一个传统的主键，其他东西（如自动索引）附加到他们身上。但是这些东西并不需要附加到主键上，主键不是那些其他东西所必需的。
SQL只允许你声明一个PRIMARY KEY，因为只有＆＃34;假设＆＃34;成为一个主键，但这并不意味着有充分的理由在附加功能之外声明任何内容。无论如何，SQL PRIMARY KEY实际上意味着UNIQUE NOT NULL，即超级密钥，而不是候选密钥，所以只有在UNIQUE NOT NULL的适当子集上没有声明PRIMARY KEY时才这样做列是它声明一个主键。因此，SQL PRIMARY KEY不一定是主键的事实表明声称对主键的需求是多么空。 （并且SQL FOREIGN KEY不是外键，因为它们不会引用任何但只有候选键（应该如此），甚至只引用任何但只有主键，或者甚至只引用{ {1}} s，它们只引用任何超级密钥。所以再次说明主键必要性的说法是空的。）
大多数SQL DBMS会自动且特别地索引PRIMARY KEY。但这只是向用户揭示某些实施方式的某种方式。
有时声称，使用单一方式引用核心业务实体可以证明拥有基表主键。但是，任何表表达式的任何超级键，即任何一个候选键的任何超集，都标识任何包含的超级键所做的一切（包括主键）。因此，即使实体的主键列不存在，查询仍然可以具有标识它的列。此外，任何表表达式的任何超级键都标识某个实体，无论它是否在某个基表中被标识（更不用说通过主键）。此外，即使通过查询对列进行了预测/ PRIMARY KEY，其行的含义仍然是根据保存这些列的表的含义。因此，查询，更新或约束可以再次涉及核心业务实体，而不存在其指定的主键列。并且它可以涉及没有关联的基本主键列的派生实体。因此声称主键是必需的或基本的或唯一识别是没有根据的。
答案 3 :(得分：0)
使用单个唯一值标识特定行/元组。
答案 4 :(得分：0)
我知道这已关闭但是......
ALTER TABLE table_name ADD CONSTRAINT pk_name 主键（C1，C2，C3）
你可以拥有一个，两个，三个....组合的PK。