在许多课程、书籍和工作中，我都看到过定义为VARCHAR(255)的文本字段作为“短”文本的默认值。除了作为一个漂亮的整数，255的长度被如此频繁地选择有什么好的原因吗?它是过去某段时间的坚持，当时有一个很好的理由(无论它是否适用于今天)?
当然，我意识到，如果你知道弦的最大长度，更严格的限制会更理想。但是如果您正在使用VARCHAR(255)，这可能表明您不知道最大长度，只知道它是一个“短”字符串。
注意:我发现这个问题(varchar(255) v tinyblob v tinytext)，它说varchar(n)需要n+1字节的存储n<=255, n+2字节的存储n>255。这是唯一的原因吗?这似乎有点随意，因为与VARCHAR(256)相比，您只节省了两个字节，而通过将其声明为VARCHAR(253)，您也可以轻松地节省另外两个字节。
之所以使用255，是因为它是一个8位数字可以计算的最大字符数。它最大限度地利用了8位计数，而不需要另一个字节来计数255以上的字符。
当以这种方式使用时，VarChar仅使用字节数+ 1来存储文本，因此不妨将其设置为255，除非您希望对字段中的字符数进行硬性限制(例如50)。
无符号的1字节数可以包含[0-255]的范围。所以当你看到255时，主要是因为程序员以10为基数思考(懂了吗?):)
实际上，在一段时间内，255是你在MySQL中可以给VARCHAR的最大大小，在索引和其他问题上使用VARCHAR比TEXT有优势。
可能是因为SQL Server和Sybase(举两个我熟悉的例子)过去在VARCHAR列中的最大字符数是255。对于SQL Server，这在1996/1997年左右的版本7中发生了变化…但旧习惯有时很难改掉。
我将回答字面上的问题:不，您看到VARCHAR(255)如此频繁地使用并没有什么好的原因(正如在其他答案中讨论的那样，确实有一些原因，只是不是好的原因)。因为架构师选择了VARCHAR(300)而不是VARCHAR(255)而导致项目灾难性失败的例子并不多。即使您谈论的是CHAR而不是VARCHAR，这也是一个几乎完全无关紧要的问题。
注意:我发现这个问题(varchar(255) v tinyblob v tinytext)，它说varchar(n)需要n+1字节的存储n<=255, n+2字节的存储n>255。这是唯一的原因吗?这似乎有点随意，因为与VARCHAR(256)相比，您只节省了两个字节，而通过将其声明为VARCHAR(253)，您也可以轻松地节省另外两个字节。
不。声明253并不会节省两个字节。 varchar的实现很可能是一个长度计数器和一个可变长度、非终止数组。这意味着如果您将“hello”存储在varchar(255)中，您将占用6个字节:一个字节用于长度(数字5)，5个字节用于5个字母。
在许多应用程序中，比如msooffice(直到版本2000或2002)，每个单元格的最大字符数是255。从每个字段处理超过255个字符的程序中移动数据到这些应用程序是一场噩梦。目前，限制的阻碍越来越小。
当你说2^8时，你得到256，但在计算机术语中，数字是从0开始的。然后你得到255，你可以在IP的网络掩码中探测它或者在IP本身中探测它。
255是8位整数的最大值:11111111 = 255
这有用吗?
另一个原因可能是在Windows上非常旧的数据访问库中，如RDO和ADO (COM版本而不是ADO.NET)，你必须调用一个特殊的方法GetChunk来从超过255个字符的列中获取数据。如果将varchar列限制为255，则不需要额外的代码。
0000 0000 -> 8位二进制数。数字代表位。
你可以这样数:
0000 0000→(0)
0000 0001→(1)
0000 0010→(2)
0000 0011→(3)
每个位可以是两个值之一:开或关。总最大值可以用乘法表示:
2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 - 1 = 255
Or
2^8 - 1.
减去1是因为第一个数是0。
255可以容纳相当多的值(没有双关的意思)。
当我们使用更多的比特时，最大值呈指数增长。因此，对于许多目的来说，添加更多的比特是多余的。
