不确定性能的影响，但它似乎是一个可能的妥协，至少在开发过程中，将包括自动递增的整数“代理”键，以及您预期的唯一的“自然”键。这将使您有机会评估性能以及其他可能的问题，包括自然键的可变性。

您提出了一个很好的观点，即可以通过使用所谓的自然键而不是代理键来避免一些连接查询。只有您才能评估这样做的好处在您的应用程序中是否显著。

也就是说，您可以测量应用程序中对快速最重要的查询，因为它们处理大量数据或执行非常频繁。如果这些查询可以从消除连接中获益，并且不会因使用varchar主键而遭受损失，那么就这样做。

不要对数据库中的所有表使用这两种策略。在某些情况下，天然键可能更好，但在其他情况下，替代键可能更好。

另一些人提出了一个很好的观点，即在实践中，自然键很少永远不会更改或有重复，因此代理键通常是值得的。

取决于长度..如果varchar是20个字符，而int是4，那么如果你使用int类型，你的索引在磁盘上每页索引空间的节点数将是原来的5倍……这意味着遍历索引将需要五分之一的物理和/或逻辑读取。

因此，如果性能是一个问题，如果有机会，总是为您的表使用一个整体的无意义键(称为代理)，对于引用这些表中的行的外键……

同时，为了保证数据一致性，每个重要的表也应该有一个有意义的非数字替代键(或唯一索引)，以确保不能插入重复的行(基于有意义的表属性的重复)。

对于您所谈论的特定用途(如状态查找)，这真的无关紧要，因为表的大小是如此之小。一般来说，在小于几千行的表上建立索引对性能没有影响……

在HauteLook，我们将许多表改为使用自然键。我们确实体验到了真实世界的性能提升。正如您所提到的，我们的许多查询现在使用更少的连接，这使得查询的性能更高。如果有意义，我们甚至会使用复合主键。话虽如此，有些表如果有代理键就更容易使用。

另外，如果您让人们编写到您的数据库的接口，代理键可能会很有帮助。第三方可以依赖代理键只在非常罕见的情况下才会更改这一事实。

代理AUTO_INCREMENT有害的常见情况:

常见的模式模式是多对多映射:

CREATE TABLE map (
    id ... AUTO_INCREMENT,
    foo_id ...,
    bar_id ...,
    PRIMARY KEY(id),
    UNIQUE(foo_id, bar_id),
    INDEX(bar_id) );

这种模式的性能要好得多，特别是在使用InnoDB时:

CREATE TABLE map (
    # No surrogate
    foo_id ...,
    bar_id ...,
    PRIMARY KEY(foo_id, bar_id),
    INDEX      (bar_id, foo_id) );

Why?

InnoDB二级键需要额外的查找;通过将配对移动到PK中，这在一个方向上是避免的。 二级索引是“覆盖”的，因此不需要额外的查找。 这个表变小了，因为去掉了id和一个索引。

另一个案例(国家):

country_id INT ...
-- versus
country_code CHAR(2) CHARACTER SET ascii

新手经常将country_code规范化为4字节INT，而不是使用“自然的”2字节，几乎不变的2字节字符串。更快、更小、更少的join，更可读。

我也面临着同样的困境。我用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调优和集群工作。