[随笔]豆包的解释：为什么MySQL里常用varchar(64)和varchar(255)，而不是varchar(256)

平常看到的时候，想着应该是255=256-1，256=2的8次方，是不是因为有长度限制？

比如，以前配置固定IPv4地址时，最常见的子网掩码不就是255.255.255.0。

刚才直接问了下豆包：

作为一个数据库专家，请解释一下为什么我们在MySQL数据库中常用varchar(64)和varchar(255)，后者为什么不是varchar（256）？

有以下原因：

从存储空间角度

• varchar(64)：

通常适用于存储一些相对较短但又不是特别固定长度的字符串，比如一些编码、小型标签、简单的名称等。64的长度可以满足很多常见的中等长度的文本数据存储需求，同时在存储空间上也比较适中，不会浪费过多空间。

• varchar(255)

当定义varchar长度小于等于255时，长度标识位需要一个字节；当大于255时，长度标识位需要两个字节。所以varchar(255)实际占用空间相对合理，只比字符串本身多1个字节用于记录长度。

而varchar(256)需要额外多占用1个字节的长度标识位，从空间利用的精细角度看不太划算。

从索引限制角度

• varchar(64)

在创建索引时，较短的长度可以让索引结构更加紧凑，索引的维护和查询效率相对较高。对于一些需要频繁进行索引查找和排序的操作，varchar (64) 的索引性能优势明显。

• varchar(255)

在 MySQL 5.6 及以前版本中，InnoDB 存储引擎的表索引前缀长度最长是 767 字节，在 utf8 编码下，255*3=765 字节，正好是能建索引情况下较接近最大值的一个选择。这使得在大部分情况下，如果需要对该字段建立索引，varchar (255) 能够很好地满足需求且不会超出索引长度限制。

从历史和兼容性角度

• varchar(64)

在一些早期的数据库设计规范和实践中，64 是一个经常被采用的标准长度，很多系统和框架在默认配置或示例中也常使用 varchar (64)，这形成了一定的历史惯例和行业规范，为了保持与现有系统、框架的兼容性和一致性，很多开发人员也会选择使用 varchar (64)。

• varchar(255)

在 MySQL 5.0.3 之前，varchar 只支持 0-255byte。尽管后续版本支持到了更大长度，但历史习惯和兼容性使得 varchar (255) 仍然被广泛使用。

从性能优化角度

• varchar(64)

在内存使用和查询处理等方面，相对较短的 varchar (64) 在数据处理速度上会有一定优势。比如在连接查询、分组查询等操作中，处理 64 长度的字符串比处理更长的字符串要快，能减少 CPU 的运算量和内存的占用。

• varchar(255)

在很多场景下，255 的长度能够满足大多数常规字符串数据的存储需求，避免了使用更大长度如 varchar (256) 及以上可能带来的性能开销，如数据页分裂、磁盘 I/O 增加等问题。同时在进行一些数据比较、排序等操作时，其性能也能保持在一个较好的水平。

参考文章

豆包参考了以下文章¹
[1]: https://blog.csdn.net/songkai558919/article/details/119856984
[2]: https://blog.csdn.net/weixin_33873956/article/details/113286147
[3]: https://blog.csdn.net/u012516166/article/details/110132358

---

1. 我没有贴掘金和云栖社区的帖子链接，因为里面有明显的错误，比如他/她说“MySQL对UTF-8的支持也仅仅限于1~3字节编码长度”。 ↩︎