我也面临着同样的困境。我用3个事实表做了一个DW(星座模式)，道路事故，事故中的车辆和事故中的伤亡。数据包括1979年至2012年英国所有事故记录，以及60个维度表。总共大约有2000万条记录。

事实表关系:

+----------+          +---------+
| Accident |>--------<| Vehicle |
+-----v----+ 1      * +----v----+
     1|                    |1
      |    +----------+    |
      +---<| Casualty |>---+
         * +----------+ *

旋风:MySQL

Accident索引本身是一个varchar(数字和字母)，有15个数字。我试着不使用代理键，一旦事故索引将永远不会改变。 在i7(8核)计算机中，根据不同的维度，在负载记录达到1200万条之后，DW的查询速度变得太慢。 经过大量的重新工作和添加bigint代理键后，我得到了平均20%的速度性能提升。 虽然性能增益较低，但有效尝试。我在MySQL调优和集群工作。

请允许我说，考虑到性能范围(开箱即用定义)，肯定有区别:

1-在应用程序中使用代理int更快，因为你不需要在你的代码或查询中使用ToUpper()， ToLower()， ToUpperInvarient()或ToLowerInvarient()，这4个函数有不同的性能基准。请参阅关于此的Microsoft性能规则。(申请的表现)

2-使用代理int保证不随时间改变键。甚至国家代码也可能发生变化，请参阅维基百科ISO代码如何随时间变化。这将花费大量时间来更改子树的主键。(数据维护的表现)

3- ORM解决方案似乎有问题，比如当PK/FK不是int时NHibernate。开发人员(性能)

这个问题是关于MySQL的，所以我说有很大的区别。如果是关于Oracle(它将数字存储为字符串——是的，一开始我不敢相信)，那么没有太大区别。

表中的存储不是问题，更新和引用索引才是问题。涉及基于主键查找记录的查询非常频繁——您希望它们尽可能快地出现，因为它们经常发生。

问题是CPU自然地处理4字节和8字节的整数，在硅中。它比较两个整数真的很快——它发生在一个或两个时钟周期内。

现在看一个字符串——它由很多字符组成(现在每个字符超过一个字节)。比较两个字符串的优先级不能在一个或两个循环中完成。相反，字符串的字符必须迭代，直到发现差异。我确信在某些数据库中有一些技巧可以让它更快，但在这里这无关紧要，因为在硅中，CPU会自然地进行int比较，并且速度很快。

我的一般规则-每个主键都应该是一个自动递增的INT，特别是在使用ORM (Hibernate, Datanucleus，等等)的OO应用程序中，对象之间有很多关系-它们通常总是作为一个简单的FK实现，DB快速解析这些关系的能力对你的应用程序很重要。 响应性。

对于短代码，可能没有区别。当保存这些代码的表可能非常小(最多几千行)并且不经常更改(我们上一次添加新的US State是什么时候)时，这一点尤其正确。

对于键之间变化较大的大型表，这可能是危险的。例如，考虑使用user表中的电子邮件地址/用户名。如果你有几百万用户，其中一些用户有很长的名字或电子邮件地址，会发生什么?现在，任何时候你需要使用这个键来连接这个表，它就变得非常昂贵。

这与性能无关。这是关于什么是一个好的主键。独一无二且随时间不变。您可能认为国家代码之类的实体永远不会随着时间而改变，并且是主键的良好候选者。但痛苦的经验是，这种情况很少发生。

INT AUTO_INCREMENT满足“唯一且随时间不变”的条件。因此才会有偏好。

绝对不是。

我做过几次……几个……INT, VARCHAR和CHAR之间的性能检查。

有一个PRIMARY KEY(唯一的和聚集的)的1000万条记录表，无论我使用哪一个都具有完全相同的速度和性能(以及子树成本)。

话虽如此……使用最适合您的应用程序的任何东西。不要担心性能。