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

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

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

是的，但除非您希望有数百万行，否则不使用基于字符串的键(因为它较慢)通常是“过早优化”。毕竟，字符串存储为大数字，而数字键通常存储为较小的数字。

不过，要注意的一件事是，如果您在任意键上聚集了索引，并且在索引中进行了大量的非顺序插入。写入的每一行都将导致索引重新写入。如果您正在进行批量插入，这确实会降低过程的速度。

默认情况下，ASPNetUserIds是128字符字符串，性能很好。

如果键必须是唯一的在表中，它应该是键。这是为什么;

主字符串键=正确的数据库关系，1个字符串键(主)和1个字符串索引(主)。

另一个选项是一个典型的int Key，但如果字符串必须是唯一的，你仍然可能需要添加一个索引，因为不停的查询来验证或检查它的唯一性。

所以使用int标识键=不正确的DB关系，1 int键(主)，1 int索引(主)，可能是唯一的字符串索引，手动验证相同的字符串不存在(类似sql检查可能)。

为了在主键上使用int而不是字符串获得更好的性能，当字符串必须是唯一的时，它将不得不是一个非常奇怪的情况。我总是喜欢使用字符串键。根据经验，除非需要，否则不要对数据库进行反规格化。

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

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

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

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

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

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

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

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

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