对所有基于文本的字段使用通用varchar（255）有不利之处吗？

我有一个contacts包含字段，如表postcode，first name，last

name，town，country，phone

number等等，所有这些都被定义为VARCHAR(255)即使没有这些领域都不会接近有255个字符。（如果您想知道，那就是这种方式，因为Ruby

on Rails迁移VARCHAR(255)默认将String字段映射到String字段，而我从不费心重写它）。

由于VARCHAR将仅存储字段的实际字符数（以及字段长度），因此，使用VARCHAR(16)over

相比有什么明显的优势（性能或其他方面）VARCHAR(255)？

此外，这些字段中的大多数都有索引。字段上较大的VARCHAR大小是否会完全影响索引的大小或性能？

仅供参考，我正在使用MySQL 5。

在存储中，VARCHAR(255)它足够聪明，可以仅存储给定行上所需的长度，而CHAR(255)后者通常会存储255个字符。

但是，由于您使用MySQL标记了此问题，因此我将提到一个MySQL特定的技巧：将行从存储引擎层复制到SQL层时，VARCHAR将转换字段CHAR以获得利用固定宽度行的优势。因此，内存中的字符串将

声明的VARCHAR列。

当查询隐式生成临时表时（例如在排序或时）GROUP

BY，这会占用大量内存。如果您使用很多VARCHAR(255)字段来存储不需要那么长的数据，这会使临时表变得非常大。

您可能还想知道，这种“填充”行为意味着，即使您存储的是单字节内容的字符串（例如ascii或latin1字符），用utf8字符集声明的字符串也每个字符填充至三个字节。同样，utf8mb4字符集会使字符串在内存中每个字符填充到四个字节。

因此，VARCHAR(255)在utf8中，存储诸如“无意见”之类的短字符串的磁盘上需要11个字节（十个低字符集字符，再加上一个字节的长度），但是在内存中则需要765个字节，因此在临时表或排序结果中也是如此。

我曾帮助不知不觉地频繁创建1.5GB临时表并填满磁盘空间的MySQL用户。他们有很多VARCHAR(255)列，实际上存储很短的字符串。

最好根据要存储的数据类型定义列。如其他人所提到的，它具有强制执行与应用程序相关的约束的好处。但是它具有避免上面所述的内存浪费的物理好处。

当然，很难知道最长的邮政地址是什么，这就是为什么许多人选择的长度VARCHAR肯定比任何地址都要长的原因。通常使用255，因为它是a的最大长度VARCHAR，该长度可以用一个字节编码。它也是VARCHARMySQL早于5.0

的最大长度。