有些人使用术语“主键”来确切地表示一个整型列，它的值是由某种自动机制生成的。例如MySQL中的AUTO_INCREMENT或Microsoft SQL Server中的IDENTITY。你是在使用主键吗?

如果是，答案取决于您使用的数据库的品牌。在MySQL中，你不能这样做，你会得到一个错误:

mysql> create table foo (
  id int primary key auto_increment, 
  id2 int auto_increment
);
ERROR 1075 (42000): Incorrect table definition; 
there can be only one auto column and it must be defined as a key

在其他一些数据库中，您可以在一个表中定义多个自动生成列。

他们给出了比我更好的技术答案。 我只能补充一下这个话题:

如果你想要一些不被允许/可接受的东西，这是一个很好的理由后退一步。

理解为什么这是不可接受的核心原因。 挖掘更多的文档/期刊文章/网络等。 分析/审查当前设计并指出主要缺陷。 在新设计中考虑和测试每一个步骤。 永远向前看，努力创造适应性的解决方案。

希望它能帮助到一些人。

只能有一个主键，但可以在主键中有多个列。

你也可以在你的表上有唯一索引，这将有点像一个主键，因为它们将强制唯一的值，并将加快这些值的查询。

(我一直在研究这些，很多)

候选键——唯一标识表行所需的最小列组合。 复合键- 2个或更多列。

一个表中可以存在多个候选键。 主键-只有一个候选键是由我们选择的 备用键-所有其他候选键 主键和备用键都可以是复合键

来源: https://en.wikipedia.org/wiki/Superkey https://en.wikipedia.org/wiki/Candidate_key https://en.wikipedia.org/wiki/Primary_key https://en.wikipedia.org/wiki/Compound_key

主键是唯一标识一条记录并在所有索引中使用的键。这就是为什么你只能有一个。它通常也是用于连接子表的键，但这不是必需的。PK的真正目的是确保某些东西允许您惟一地标识一条记录，这样数据更改就会影响正确的记录，从而可以创建索引。

However, you can put multiple fields in one primary key (a composite PK). This will make your joins slower (espcially if they are larger string type fields) and your indexes larger but it may remove the need to do joins in some of the child tables, so as far as performance and design, take it on a case by case basis. When you do this, each field itself is not unique, but the combination of them is. If one or more of the fields in a composite key should also be unique, then you need a unique index on it. It is likely though that if one field is unique, this is a better candidate for the PK.

Now at times, you have more than one candidate for the PK. In this case you choose one as the PK or use a surrogate key (I personally prefer surrogate keys for this instance). And (this is critical!) you add unique indexes to each of the candidate keys that were not chosen as the PK. If the data needs to be unique, it needs a unique index whether it is the PK or not. This is a data integrity issue. (Note this is also true anytime you use a surrogate key; people get into trouble with surrogate keys because they forget to create unique indexes on the candidate keys.)

There are occasionally times when you want more than one surrogate key (which are usually the PK if you have them). In this case what you want isn't more PK's, it is more fields with autogenerated keys. Most DBs don't allow this, but there are ways of getting around it. First consider if the second field could be calculated based on the first autogenerated key (Field1 * -1 for instance) or perhaps the need for a second autogenerated key really means you should create a related table. Related tables can be in a one-to-one relationship. You would enforce that by adding the PK from the parent table to the child table and then adding the new autogenerated field to the table and then whatever fields are appropriate for this table. Then choose one of the two keys as the PK and put a unique index on the other (the autogenerated field does not have to be a PK). And make sure to add the FK to the field that is in the parent table. In general if you have no additional fields for the child table, you need to examine why you think you need two autogenerated fields.

一个表可以有多个候选键。每个候选键都是一个列或一组列，它们是UNIQUE的，加在一起也是NOT NULL。因此，为任何候选键的所有列指定值就足以确定是否有一行满足条件，或者根本没有行。

候选键是关系数据模型中的一个基本概念。

通常的做法是，如果一个表中存在多个键，则将其中一个候选键指定为主键。通常的做法是使表的任何外键引用主键，而不是任何其他候选键。

我推荐这些实践，但是关系模型中没有要求在候选键中选择主键。