It used to be that all strings required a NUL terminator, or "backslash-zero". Updated databases don't have that. It was "255 characters of text" with a "\0" added automatically at the end so the system knew where the string ended. If you said VARCHAR(256), it would end up being 257 and then you'd be in the next register for one character. Wasteful. That's why everything was VARCHAR(255) and VARCHAR(31). Out of habit the 255 seems to have stuck around but the 31's became 32's and the 511's became 512's. That part is weird. It's hard to make myself write VARCHAR(256).

我想这也许能回答你的问题。看起来这是早期系统中varchar的最大限制。我从另一个stackoverflow问题上偷来的。

当然，很难知道最长的邮政地址是什么，这就是为什么许多人选择一个长VARCHAR，它肯定比任何地址都长。255是常用的，因为它可能是早期某些数据库中VARCHAR的最大长度(PostgreSQL直到最近也是如此)。

对所有基于文本的字段使用通用varchar(255)是否有缺点?

是否存在其他提供性能好处的级别?例如，varchar(512)的性能是否低于varchar(511)或varchar(510)?

回顾一下位/字节存储的基本原理，存储256以下的整数需要一个字节，存储256到65536之间的整数需要两个字节。 因此，它需要相同的空间(两个字节)来存储511或512或65535.... 因此，对于varchar(512)或varchar(511)，上面讨论中提到的this参数显然是N/A。

最大长度为255个字符，DBMS可以选择使用一个字节来表示字段中数据的长度。如果限制为256或更大，则需要两个字节。

长度为0的值对于varchar数据当然有效(除非另有约束)。大多数系统将这样的空字符串与NULL区别对待，但一些系统(特别是Oracle)将空字符串与NULL相同。对于空字符串不是NULL的系统，需要在行中的某个位置添加一个额外的位来指示该值是否应该被视为NULL。

正如你所注意到的，这是一个历史优化，可能与今天的大多数系统无关。

8位unsigned = 256字节

长度为255个字符+字节0

255是可以存储在单字节无符号整数(假设8位字节)中的最大数值——因此，出于某种目的存储字符串长度的应用程序更喜欢255而不是256，因为这意味着它们只需要为“size”变量分配1个字节。