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

在这种情况下，使用字符串作为自然的主键几乎总是更好的，只要您可以信任它。如果是字符串也不用担心，只要字符串足够短，比如说最多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 =…)进行有条件的查询和连接。

Technically yes, but if a string makes sense to be the primary key then you should probably use it. This all depends on the size of the table you're making it for and the length of the string that is going to be the primary key (longer strings == harder to compare). I wouldn't necessarily use a string for a table that has millions of rows, but the amount of performance slowdown you'll get by using a string on smaller tables will be minuscule to the headaches that you can have by having an integer that doesn't mean anything in relation to the data.

指数意味着大量的比较。

通常，字符串比整数长，并且可以应用排序规则进行比较，因此比较字符串通常比比较整数需要更多的计算量。

不过，有时使用字符串作为主键要比使用字符串与数字id表进行额外的连接更快。

变量太多了。这取决于表的大小，索引，字符串键域的性质…

一般来说，整数会更快。但差别大到足以让人在意吗?这很难说。

另外，你选择字符串的动机是什么?数字型的自动递增键通常也容易得多。是语义上的吗?方便?复制/断开连接问题?你的回答可能会限制你的选择。这也会让你想起你忘记的第三个“混合”选项:Guids。

使用string作为主键的另一个问题是，由于索引不断按顺序排列，当创建一个新键时，索引必须重新排序……如果使用自动编号整数，则新键只添加到索引的末尾。