可能重复：
Surrogate Vs. Natural/Business Keys
When not to use surrogate primary keys?
所以，我更希望将INT作为AI的主键。但是，这就是我考虑将唯一字符串作为主键的原因：我不必查询相关表来获取主键，因为我已经知道了。
例如：
我有很多关系：
客户 - 订单 - 产品
假设我想添加新客户和新订单，我已经知道他们买了什么。我必须在产品表上进行查询以获取INT，但如果我有一个主键的字符串（唯一），我不必进行查询（这对我来说似乎更清晰，我不是谈论优化/运行时速度，根本不是。）
答案 0 :(得分：4)
如果您不担心优化，主键的主要2个标准是：
唯一
Constanteness（永不改变）
E.g。如果您的问题域是 - 并且将永远是 - 这样两个产品名称总是不同的，并且没有产品会更改其名称（想想Norton Antivirus - ＆gt; Symantec Antivirus以获取名称更改的简单示例），那么您可以使用产品名称作为唯一键。
这两个必须100％真实，不仅在今天，而且对于数据库的任何可预见的未来生命周期。
因此，强烈建议使用数字ID，因为您可能无法总是预见到这些事情 - 稍后更改数据库结构以获得产品ID当然比需要映射的轻微不便要差几个数量级。来自查询中名称的ID。
答案 1 :(得分：3)
如果你可以保证你的VARCHAR字段确实是唯一的并且希望稳定（不改变），那么你绝对可以将它用作主键而不会出现任何概念问题。
使用它作为主键（或者更重要的是：SQL Server中的群集密钥）的唯一真正原因确实是基于性能的。更广泛且不同大小的聚类键在许多方面都是次优的，不仅会影响您的表及其聚簇索引，还会影响该表上的所有非聚簇索引。但如果你不关心这一点，那么你可以使用VARCHAR作为主键。
答案 2 :(得分：0)
呃......两种方式都是正确的