不要担心性能，直到您获得了一个简单而合理的设计，该设计与数据描述的主题一致，并且非常适合数据的预期用途。然后，如果出现性能问题，您可以通过调整系统来处理它们。

在这种情况下，使用字符串作为自然的主键几乎总是更好的，只要您可以信任它。如果是字符串也不用担心，只要字符串足够短，比如说最多25个字符。就性能而言，你不会付出很大的代价。

数据输入人员或自动数据源是否总是为假定的自然键提供一个值，还是有时会省略?输入数据偶尔会出错吗?如果是，如何检测和纠正错误?

指定查询的程序员和交互用户能够使用自然键来获得他们想要的东西吗?

如果你不相信天然的钥匙，那就找一个替代品。如果你发明了一个代理，你也可以发明一个整数。然后，您必须考虑是否对用户社区隐藏代理。一些没有隐藏代理键的开发人员后来后悔了。

我可能会使用一个整数作为你的主键，然后把你的字符串(我假设它是某种ID)作为一个单独的列。

create table sample (
  sample_pk             INT NOT NULL AUTO_INCREMENT,
  sample_id             VARCHAR(100) NOT NULL,
  ...
  PRIMARY KEY(sample_pk)
);

您总是可以对字符串(ID)列(其中sample_id =…)进行有条件的查询和连接。

你为什么要用字符串作为主键?

我只需将主键设置为一个自动递增的整数字段，并在字符串字段上放置一个索引。

这样，如果您在表上进行搜索，它们应该相对较快，并且所有的连接和正常查找都不会受到速度的影响。

您还可以控制被索引的字符串字段的数量。换句话说，如果您认为这样就足够了，您可以说“只索引前5个字符”。或者如果您的数据可以相对相似，您可以索引整个字段。

Strings are slower in joins and in real life they are very rarely really unique (even when they are supposed to be). The only advantage is that they can reduce the number of joins if you are joining to the primary table only to get the name. However, strings are also often subject to change thus creating the problem of having to fix all related records when the company name changes or the person gets married. This can be a huge performance hit and if all tables that should be related somehow are not related (this happens more often than you think), then you might have data mismatches as well. An integer that will never change through the life of the record is a far safer choice from a data integrity standpoint as well as from a performance standpoint. Natural keys are usually not so good for maintenance of the data.

我还想指出，两者的最佳方法通常是使用自递增键(或者在某些特殊情况下，使用GUID)作为PK，然后在自然键上放置唯一索引。您可以获得更快的连接，不会得到重复的记录，也不必因为公司名称更改而更新一百万个子记录。

使用什么作为主键并不重要，只要它是UNIQUE即可。如果您关心速度或良好的数据库设计，请使用int型，除非您计划复制数据，否则请使用GUID。

如果这是一个访问数据库或一些小应用程序，那么谁真的在乎。我认为，我们大多数开发人员之所以把旧的int或guid放在前面，是因为我们有一种方式来发展项目，并且您希望给自己留下发展的选择。

在PK列中使用整数有两个原因:

我们可以为自动递增的整数字段设置标识。 当我们创建pk时，db会创建一个索引(Cluster或Non Cluster)，在数据存储到表之前对其进行排序。通过在PK上使用标识，优化器在保存记录之前不需要检查排序顺序。这提高了大表的性能。