我看到VARCHAR(255)如此频繁地使用(而不是其他长度)，有什么好的原因吗?

在许多课程、书籍和工作中，我都看到过定义为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)，您也可以轻松地节省另外两个字节。

180332 次浏览
小开

之所以使用255，是因为它是一个8位数字可以计算的最大字符数。它最大限度地利用了8位计数，而不需要另一个字节来计数255以上的字符。

当以这种方式使用时，VarChar仅使用字节数+ 1来存储文本，因此不妨将其设置为255，除非您希望对字段中的字符数进行硬性限制(例如50)。

小开
最佳答案

从历史上看，255字符通常是某些dbms中VARCHAR的最大长度，如果你想使用UTF-8并对列进行索引(因为索引长度限制)，它有时仍然是有效的最大长度。

小开

无符号的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)，您也可以轻松地节省另外两个字节。

< p >。声明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位二进制数。数字代表位。

你可以这样数:

__abc0→(0)

__abc0→(1)

__abc0→(2)

__abc0→(3)

每个位可以是两个值之一:开或关。总最大值可以用乘法表示:

2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 - 1 = 255

或

2^8 - 1.

减去1是因为第一个数是0。

255可以容纳相当多的值(没有双关的意思)。

当我们使用更多的比特时，最大值呈指数增长。因此，对于许多目的来说，添加更多的比特是多余的。


提交答案