我有一个contacts表，其中包含postcode、first name、last name、town、country、phone number等字段，所有这些字段都被定义为VARCHAR(255)，尽管这些字段都不会接近255个字符.(如果你想知道的话，这是因为Ruby on Rails迁移默认情况下会将字符串字段映射到VARCHAR(255)，我从来没有想过要覆盖它).
由于VARCHAR只存储字段的实际字符数(以及字段长度)，使用VARCHAR(16)比VARCHAR(255)有什么明显的优势(性能或其他方面)？
此外，大多数字段都有索引.字段上较大的VARCHAR大小是否会影响索引的大小或性能？
仅供参考，我使用的是MySQL 5.
在存储器中，VARCHAR(255)足够智能，可以只存储给定行上所需的长度，而CHAR(255)总是存储255个字符.
但是，既然您用MySQL标记了这个问题，我将提到一个MySQL特有的技巧:当行从存储引擎层复制到SQL层时，VARCHAR个字段将转换为CHAR，以获得使用固定宽度行的优势.因此，内存中的字符串变成了声明的VARCHAR列中的padded out to the maximum length个.
当查询隐式生成临时表时，例如在排序或GROUP BY时，这可能会占用大量内存.如果对不需要那么长的数据使用大量VARCHAR(255)个字段，这会使临时表非常大.
您可能还想知道，这种"填充"行为意味着使用utf8字符集声明的字符串将每个字符填充到三个字节，即使对于存储为单字节内容的字符串(例如ascii或拉丁字符).同样地，utf8mb4字符集会使字符串在内存中的每个字符填充到四个字节.
因此，一个VARCHAR(255)英寸的utf8存储一个短字符串，比如"No opinion"，在磁盘上需要11个字节(10个较低的字符集字符，加上一个字节的长度)，但在内存中需要765个字节，因此在临时表或排序结果中也需要765个字节.
我帮助过MySQL用户，他们在不知不觉中频繁创建了1.5GB临时表，并填满了他们的磁盘空间.它们有很多VARCHAR(255)列，实际上存储的是非常短的字符串.
最好根据要存储的数据类型定义列.正如其他人所提到的，强制实施与应用程序相关的约束是有好处的.但它有物理上的好处，可以避免我上面描述的内存浪费.
当然，很难知道最长的邮政地址是什么，这就是为什么许多人 Select 了比任何地址都长的长VARCHAR.255是常用的，因为它是VARCHAR的最大长度，长度可以用一个字节编码.它也是MySQL中超过5.0的最大VARCHAR长度.