INT和VARCHAR主键之间有真正的性能差异吗?

在MySQL中使用INT和VARCHAR作为主键之间有可测量的性能差异吗?我想使用VARCHAR作为参考列表的主键(认为美国州，国家代码)和同事不会在INT AUTO_INCREMENT作为所有表的主键上让步。

我的论点是，INT和VARCHAR之间的性能差异可以忽略不计，因为每个INT外键引用都需要一个JOIN来理解引用，VARCHAR键将直接显示信息。

那么，有人对这个特殊的用例以及与之相关的性能问题有过经验吗?

当前回答

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

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

其他回答

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

至于主键(Primary Key)，任何物理上使行唯一的元素都应该被确定为主键。

对于作为外键的引用，使用自动递增的整数作为代理是一个好主意，主要有两个原因。 -首先，通常在连接中产生的开销更少。 -其次，如果你需要更新包含唯一varchar的表，那么更新必须级联到所有的子表，并更新所有的子表以及索引，而使用int代理，它只需要更新主表及其索引。

使用代理的缺点是，你可能会允许更改代理的含义:

ex.
id value
1 A
2 B
3 C

Update 3 to D
id value
1 A
2 B
3 D

Update 2 to C
id value
1 A
2 C
3 D

Update 3 to B
id value
1 A
2 C
3 B

这完全取决于您在结构中真正需要担心的是什么，以及什么最重要。

代理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，更可读。

绝对不是。

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

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

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

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

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

推荐文章