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

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

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

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

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

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

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

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

从性能的角度来看-与使用整数(PK)实现的性能相比，Yes字符串(PK)将降低性能，其中PK—>主键。

From requirement standpoint - Although this is not a part of your question still I would like to mention. When we are handling huge data across different tables we generally look for the probable set of keys that can be set for a particular table. This is primarily because there are many tables and mostly each or some table would be related to the other through some relation ( a concept of Foreign Key ). Therefore we really cannot always choose an integer as a Primary Key, rather we go for a combination of 3, 4 or 5 attributes as the primary key for that tables. And those keys can be used as a foreign key when we would relate the records with some other table. This makes it useful to relate the records across different tables when required.

因此，为了优化使用-我们总是将1或2个具有1或2个字符串属性的整数组合在一起，但同样只是在需要时才这样做。

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

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

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

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

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

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

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