有没有一个很好的理由我经常使用VARCHAR(255)(而不是另一个长度)？

Question

有没有一个很好的理由我经常使用VARCHAR(255)(而不是另一个长度)？

Kip*_*Kip 138 database varchar database-design types

在多个课程,书籍和工作中,我看到将文本字段定义为VARCHAR(255)作为"短"文本的默认类型.有没有什么好的理由经常选择长度为255,而不是一个漂亮的圆数？在有充分理由(无论今天是否适用)的情况下,过去的某个时间是坚持吗？

当然,我意识到,如果你以某种方式知道字符串的最大长度,那么更严格的限制会更理想.但是如果你使用VARCHAR(255)可能表示你不知道最大长度,那只是它是一个"短"字符串.

注意:我发现这个问题(VARCHAR(255)V TINYBLOB v TINYTEXT),它表示,VARCHAR(Ñ)需要Ñ 1个字节的存储空间用于Ñ <= 255,Ñ 2个字节的存储对的Ñ > 255.这是唯一的原因吗？这似乎有点武断,因为与VARCHAR(256)相比,你只能保存两个字节,你可以通过声明VARCHAR(253)轻松地保存另外两个字节.

Answer 1

Rob*_*vey 150

使用255是因为它是可以用8位数计数的最大字符数.它最大限度地利用了8位计数,而不需要另外的整个字节来计算255以上的字符数.

当以这种方式使用时,VarChar仅使用字节数+ 1来存储文本,因此您也可以将其设置为255,除非您想要字段中字符数的硬限制(如50).

我喜欢这句话:"轻率地要求另一个整个字节".=) (87认同)
对于varchars为UTF-8的DB,这是否适用？ (7认同)
**如果字符集是 `utf8`**，则 `varchar(85)` 是交叉将*长度字节*从 1 个字节变为 2 个字节的限制。如果是“utf8mb4”，则为“varchar(63)”。这些很重要，因为它们是通过使用在线 ALTER TABLE 可以扩展 [VARCHAR 长度的最大值](https://dev.mysql.com/doc/refman/5.7/en/innodb-create-index -overview.html#innodb-online-ddl-column-properties）。因此，我通过创建一个包含“varchar(2) charset utf8”列的表并查看在给定“ALGORITHM=INPLACE”的情况下能够将其扩展多远来得出这些数字。 (4认同)
@antak：在MySQL中，使用InnoDB，任何键列不能大于767字节。如果 VARCHAR 列是 UTF8（意味着每个字符可能最多占用 3 个字节），则该列允许的最大长度为 Floor(767/3) = 255。我假设选择“767”正是出于这个原因。 (2认同)

Answer 2

cha*_*aos 92

从历史上看,255个字符通常是VARCHAR某些DBMS 中a的最大长度,如果您想使用UTF-8并将列编入索引(由于索引长度限制),它有时仍会成为有效最大值.

@CharlesBretana：我现在已经解释了三遍，没有任何变化。MySQL的索引长度限制仍然是767字节，编码一个3字节的UTF-8字符所需的字节数仍然是3，而floor(767 / 3)仍然是255。你决心找点东西迷惑乞丐的信念. (4认同)
@CharlesBretana：我所说的“假 UTF-8”是指 MySQL 的“utf8”编码，正如我提到的，每个字符保留（并且仅限于）3 个字节。这不是一个很好的 UTF-8 版本；如果你想在 MySQL 中使用像样的 UTF-8，你必须使用它的“utf8mb4”编码。但是人们更有可能不知道这一点并使用“utf8”，并且比任何其他编码更有可能需要 UTF-8，因此，很快，他们在 VARCHAR 中的最大可索引长度为 255 个字符。尽管你感到震惊。 (3认同)
@CharlesBretana:如果您阅读了所引用的句子的其余部分,您将找到您要求的确切解释. (2认同)
@CharlesBretana 如果您仔细查看 Chaos 的答案，您会注意到它分为两部分：1. Varchar(255) 背后的历史原因如此普遍（它曾经是某些旧 DBMS 上的最大值），2.即使在今天，由于前面讨论的索引限制，它对某些人来说仍然是一个限制，第 1 部分和第 2 部分没有链接。第 1 部分是问题的实际答案，第 2 部分是与问题仍然相关的旁注，因为它解释了为什么即使在今天它仍然可能是一个限制。（续->） (2认同)

Answer 3

Cha*_*ana 19

可能是因为SQL Server和Sybase(我熟悉的两个名字)曾经在VARCHAR列中的字符数中最多包含255个字符.对于SQL Server,这在1996/1997左右的版本7中发生了变化......但旧习惯有时会很难.

引用特定数据库和版本的+1.而"老习惯难过"可能是最真实的答案. (7认同)

Answer 4

Mus*_*sis 15

我将回答字面上的问题: 不,没有一个很好的理由你经常使用VARCHAR(255)(确实存在理由,正如其他答案所讨论的那样,只是不好的理由).您将找不到灾难性失败的项目的许多示例,因为架构师选择了VARCHAR(300)而不是VARCHAR(255).即使你在谈论CHAR而不是VARCHAR,这也是一个几乎无足轻重的问题.

@EdwardBrey：如果摩尔定律仍然成立，那么我在这里的回答比我写的时候有效 16 倍。 (2认同)

Answer 5

小智 12

当你说2^8你得到256,但计算机术语中的数字从数字开始0.那么,你得到了255,你可以在互联网掩码中探测IP或IP本身.

255 是8位整数的最大值: 11111111 = 255

这有帮助吗？

Answer 6

Ste*_*ini 7

注意:我发现了这个问题(varchar(255)v tinyblob v tinytext),它表示VARCHAR(n)需要n + 1个字节的存储空间用于n <= 255,n + 2个字节的存储空间用于n> 255.这是唯一的原因吗？这似乎有点武断,因为与VARCHAR(256)相比,你只能保存两个字节,你可以通过声明VARCHAR(253)轻松地保存另外两个字节.

不,你没有通过声明253来保存两个字节.varchar的实现很可能是长度计数器和可变长度的非终止数组.这意味着如果在varchar(255)中存储"hello",则将占用6个字节:长度为一个字节(数字为5),五个字母为5个字节.

所有数据库都不适用此声明.许多数据库使用表中给定大小的varchar字段,以便在为行更改该字段时不必移动行. (2认同)
它可能是允许的,但是实现`VARCHAR`这种方式会破坏使用`VARCHAR`而不是`CHAR`的整个*点*. (2认同)

归档时间：	16 年，1 月前
查看次数：	105546 次
最近记录：	6 年，5 月前