MySQL: VARCHAR的大小和PK一样快吗？

Question

作为主键的VARCHAR列的好/安全最大长度不会比在MySQL 64位系统上使用5+ InnoDB的整数ID慢多少？请注意，应该假定此PK被其他表引用，因此它将出现在许多联接中。

VARCHAR(7)会不会是一个好的长度? 6? 8? 10？更多?少？为什么？

这可能很难回答，但至少应该有一个基于事实的上限，例如基于MySQL/InnoDB的内部工作(索引结构，. ?)。

编辑:假设ASCII字符编码，区分大小写。

Answer 1

对于键来说，使用int字段通常更可取。在现有的任何平台上，在一个汇编程序指令中都可以比较两个数字。对两个字符串进行比较总是需要预先执行一个循环和额外的设置步骤，或者即使cpu中内置了字符串比较指令，也需要使用多个cpu周期。

Answer 2

在ASCII编码中，任何大于VARCHAR(4)的内容(以及ascii_bin排序规则--对于关系操作不区分大小写的排序规则)都会比INT慢(因为INT有4个字节长)。

Answer 3

作为主键的VARCHAR列的好/安全最大长度不会比64位系统上使用MySQL 5+ InnoDB的整数ID慢多少？请注意，应该假定此PK被其他表引用，因此它将出现在许多联接中。

做什么不太慢？选择？最新消息？插入？我的内部用户需要更快的插入；我的web用户需要更快的选择。

在某种程度上，性能(不管这意味着什么)取决于特定的数据库结构、特定的查询模式和特定的服务器硬件。你自己的测试显示了什么？

可能很难回答，但至少应该有一个基于事实的上限，例如基于MySQL/InnoDB的内部工作(索引结构，. ?)。

如果有一个上限，你将无法指望它保持不变，即使是轻微的版本升级。当然，查询优化器在运行时而不是在设计时进行决策。将数据库的长期设计决策建立在数据库管理系统内部的基础上，因为它们现在存在，这不是最佳实践。(这只是一个观察。我并不是在暗示这就是你在做的事情，但是很多读过这篇文章的人都很容易这么做。)

如果您想知道一组特定的表是如何执行的，那么编辑您的问题并包含DDL是有意义的。那样的话，我们至少是在谈论同样的事情。就像现在一样，每个回答问题的人都可能会使用不同的结构。(如果他们费心去测试的话)我们可能不会透露我们的隐私--有时也是毫无根据的--假设。

在一种特殊情况下--from another SO question--使用id号和联接所花费的时间是使用自然键执行时间的100倍。(32位PostgreSQL.)所以人们可以整天谈论比较整数或字符串所需的CPU指令，整数中的字节数，UTF-8排序规则中的字节数，等等。然而，在这一具体案例中，VARCHAR(30)以压倒性优势获胜。

当我在军队的时候，我们有一句谚语。“当你的地图和地形不一致时，跟随地形。”

如果理论和测量不一致，请遵循测量方法。根据测量结果制定经验法则。