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

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

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

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

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

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

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

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

我对网上缺乏基准有点恼火，所以我自己做了一个测试。

不过请注意，我并没有定期这样做，所以请检查我的设置和步骤，以找出任何可能无意中影响结果的因素，并在评论中提出您的担忧。

设置如下:

英特尔®酷睿™i7-7500U CPU @ 2.70GHz × 4 15.6 GiB RAM，我确保在测试期间大约8gb是空闲的。 148.6 GB SSD硬盘，空闲空间充足。 Ubuntu 16.04 64位 MySQL version 14.14 Distrib 5.7.20, for Linux (x86_64)

表:

create table jan_int (data1 varchar(255), data2 int(10), myindex tinyint(4)) ENGINE=InnoDB;
create table jan_int_index (data1 varchar(255), data2 int(10), myindex tinyint(4), INDEX (myindex)) ENGINE=InnoDB;
create table jan_char (data1 varchar(255), data2 int(10), myindex char(6)) ENGINE=InnoDB;
create table jan_char_index (data1 varchar(255), data2 int(10), myindex char(6), INDEX (myindex)) ENGINE=InnoDB;
create table jan_varchar (data1 varchar(255), data2 int(10), myindex varchar(63)) ENGINE=InnoDB;
create table jan_varchar_index (data1 varchar(255), data2 int(10), myindex varchar(63), INDEX (myindex)) ENGINE=InnoDB;

然后，我用一个PHP脚本在每个表中填充了1000万行，其本质是这样的:

$pdo = get_pdo();

$keys = [ 'alabam', 'massac', 'newyor', 'newham', 'delawa', 'califo', 'nevada', 'texas_', 'florid', 'ohio__' ];

for ($k = 0; $k < 10; $k++) {
    for ($j = 0; $j < 1000; $j++) {
        $val = '';
        for ($i = 0; $i < 1000; $i++) {
            $val .= '("' . generate_random_string() . '", ' . rand (0, 10000) . ', "' . ($keys[rand(0, 9)]) . '"),';
        }
        $val = rtrim($val, ',');
        $pdo->query('INSERT INTO jan_char VALUES ' . $val);
    }
    echo "\n" . ($k + 1) . ' millon(s) rows inserted.';
}

对于int表，位($keys[rand(0,9)])被替换为rand(0,9)，而对于varchar表，我使用完整的美国州名，没有将它们删减或扩展为6个字符。Generate_random_string()生成一个10个字符的随机字符串。

然后在MySQL中运行:

SET SESSION query_cache_type=0; 对于jan_int表: SELECT count(*) FROM jan_int WHERE myindex = 5; SELECT count(*) FROM jan_int WHERE myindex = 5); 对于其他表，如上所示，对于char表使用myindex = 'california'，对于varchar表使用myindex = 'california'。

每个表上BENCHMARK查询的次数:

Jan_int: 21.30秒 Jan_int_index: 18.79秒 Jan_char: 21.70秒 Jan_char_index: 18.85秒 Jan_varchar: 21.76秒 Jan_varchar_index: 18.86秒

关于表和索引大小，下面是来自janperformancetest的显示表状态的输出;(有几列没有显示):

|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Name              | Engine | Version | Row_format | Rows    | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Collation              |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| jan_int           | InnoDB |      10 | Dynamic    | 9739094 |             43 |   422510592 |               0 |            0 |   4194304 |           NULL | utf8mb4_unicode_520_ci |  
| jan_int_index     | InnoDB |      10 | Dynamic    | 9740329 |             43 |   420413440 |               0 |    132857856 |   7340032 |           NULL | utf8mb4_unicode_520_ci |   
| jan_char          | InnoDB |      10 | Dynamic    | 9726613 |             51 |   500170752 |               0 |            0 |   5242880 |           NULL | utf8mb4_unicode_520_ci |  
| jan_char_index    | InnoDB |      10 | Dynamic    | 9719059 |             52 |   513802240 |               0 |    202342400 |   5242880 |           NULL | utf8mb4_unicode_520_ci |  
| jan_varchar       | InnoDB |      10 | Dynamic    | 9722049 |             53 |   521142272 |               0 |            0 |   7340032 |           NULL | utf8mb4_unicode_520_ci |   
| jan_varchar_index | InnoDB |      10 | Dynamic    | 9738381 |             49 |   486539264 |               0 |    202375168 |   7340032 |           NULL | utf8mb4_unicode_520_ci | 
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

我的结论是，对于这个特定的用例，没有性能差异。

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

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

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

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

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