SQL 为什么历史上人们使用 255 而不是 256 作为数据库字段大小？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2340639/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why historically do people use 255 not 256 for database field magnitudes?
提问by Andrew M
You often see database fields set to have a magnitude of 255 characters, what is the traditional / historic reason why? I assume it's something to do with paging / memory limits, and performance but the distinction between 255 and 256 has always confused me.
您经常看到数据库字段设置为 255 个字符的大小，这是传统/历史原因是什么？我认为这与分页/内存限制和性能有关，但 255 和 256 之间的区别一直让我感到困惑。
varchar(255)
Considering this is a capacity or magnitude, not an indexer, why is 255 preferred over 256?Is a byte reserved for some purpose (terminator or null or something)?
考虑到这是一个容量或大小，而不是一个索引器，为什么 255 比 256 更受欢迎？是否为某种目的保留了一个字节（终止符或空值或其他什么）？
Presumably varchar(0) is a nonsense (has zero capacity)? In which case 2^8 of space should be 256 surely?
大概 varchar(0) 是无稽之谈（容量为零）？在这种情况下，2^8 的空间肯定应该是 256？
Are there other magnitudes that provide performance benefits? For example is varchar(512) less performant than varchar(511) or varchar(510)?
是否还有其他量级可以提供性能优势？例如，varchar(512) 的性能是否低于 varchar(511) 或 varchar(510)？
Is this value the same for all relations databases, old and new?
对于所有关系数据库，旧的和新的，这个值是否相同？
disclaimer- I'm a developer not a DBA, I use field sizes and types that suit my business logic where that is known, but I'd like to know the historicreason for this preference, even if it's no longer relevant (but even more if it still is relevant).
免责声明- 我是开发人员而不是 DBA，我使用适合我已知业务逻辑的字段大小和类型，但我想知道这种偏好的历史原因，即使它不再相关（但即使如果它仍然相关，则更多）。
Edit:
编辑：
Thanks for the answers, there seems to be some concensus that a byte is used to store size, but this doesn't settle the matter definitively in my mind.
感谢您的回答，似乎有一些共识认为一个字节用于存储大小，但这并不能在我的脑海中明确解决这个问题。
If the meta data (string length) is stored in the same contiguous memory/disk, it makes some sense. 1 byte of metadata and 255 bytes of string data, would suit each other very nicely, and fit into 256 contiguous bytes of storage, which presumably is neat and tidy.
如果元数据（字符串长度）存储在同一个连续的内存/磁盘中，那是有道理的。1 字节的元数据和 255 字节的字符串数据，将非常适合彼此，并适合 256 个连续字节的存储，这大概是整洁的。
But...If the metadata (string length) is stored separately from the actual string data (in a master table perhaps), then to constrain the length of string's data by one byte, just because it's easier to store only a 1 byte integer of metadata seems a bit odd.
但是...如果元数据（字符串长度）与实际字符串数据（可能在主表中）分开存储，那么将字符串数据的长度限制为一个字节，只是因为仅存储 1 个字节的整数更容易元数据似乎有点奇怪。
In both cases, it would seem to be a subtlety that probably depends on the DB implementation. The practice of using 255 seems pretty widespread, so someone somewhere must have argued a good case for it in the beginning, can anyone remember what that case was/is? Programmers won't adopt any new practice without a reason, and this must have been new once.
在这两种情况下，这似乎是一个可能取决于数据库实现的微妙之处。使用 255 的做法似乎很普遍，所以一定有人在一开始就为它争论了一个很好的案例，有人能记得那个案例是/是什么吗？程序员不会无缘无故地采用任何新的做法，这肯定是新的一次。
采纳答案by Greg Hewgill
With a maximum length of 255 characters, the DBMS can choose to use a single byte to indicate the length of the data in the field. If the limit were 256 or greater, two bytes would be needed.
DBMS 的最大长度为 255 个字符，可以选择使用单个字节来表示字段中数据的长度。如果限制为 256 或更大，则需要两个字节。
A value of length zero is certainly valid for varchardata (unless constrained otherwise). Most systems treat such an empty string as distinct from NULL, but some systems (notably Oracle) treat an empty string identically to NULL. For systems where an empty string is not NULL, an additional bit somewhere in the row would be needed to indicate whether the value should be considered NULL or not.
长度为零的值肯定对varchar数据有效（除非另有约束）。大多数系统将这种空字符串视为与 NULL 不同，但某些系统（特别是 Oracle）将空字符串视为与 NULL 相同。对于空字符串不是 NULL 的系统，需要在行中的某处增加一个位来指示该值是否应被视为 NULL。
As you note, this is a historical optimisation and is probably not relevant to most systems today.
正如您所注意到的，这是一个历史优化，可能与当今的大多数系统无关。
回答by RedPandaCurios
255 was the varchar limit in mySQL4 and earlier.
255 是mySQL4 及更早版本中的varchar 限制。
Also 255 chars + Null terminator = 256
还有 255 个字符 + 空终止符 = 256
Or 1 byte length descriptor gives a possible range 0-255 chars
或 1 字节长度描述符给出可能的范围 0-255 个字符
回答by Amber
255 is the largest numerical value that can be stored in a single-byte unsigned integer (assuming 8-bit bytes) - hence, applications which store the length of a string for some purpose would prefer 255 over 256 because it means they only have to allocate 1 byte for the "size" variable.
255 是可以存储在单字节无符号整数（假设为 8 位字节）中的最大数值 - 因此，出于某种目的存储字符串长度的应用程序更喜欢 255 而不是 256，因为这意味着他们只需要为“size”变量分配 1 个字节。
回答by Anil Shinde
From MySQL Manual:
来自 MySQL 手册：
Data Type :
VARCHAR(M), VARBINARY(M)Storage Required:
L + 1 bytes if column values require 0 – 255 bytes, L + 2 bytes if values may require more than 255 bytes
数据类型：
VARCHAR(M), VARBINARY(M)存储要求：
如果列值需要 0 – 255 个字节，则为 L + 1 个字节，如果值可能需要超过 255 个字节，则为 L + 2 个字节
Understand and make choice.
了解并做出选择。
回答by remi bourgarel
255 is the maximum value of a 8 bit integer : 11111111 = 255.
255 是 8 位整数的最大值：11111111 = 255。
回答by MarkJ
A maximum length of 255 allows the database engine to use only 1 byte to store the length of each field. You are correct that 1 byte of space allows you to store 2^8=256 distinct values for the length of the string.
最大长度 255 允许数据库引擎仅使用 1 个字节来存储每个字段的长度。您是正确的，1 个字节的空间允许您为字符串的长度存储 2^8=256 个不同的值。
But if you allow the field to store zero-length text strings, you need to be able to store zero in the length. So you can allow 256 distinct length values, starting at zero: 0-255.
但是，如果允许字段存储零长度的文本字符串，则需要能够存储零长度。因此，您可以允许 256 个不同的长度值，从零开始：0-255。
回答by Vlad
Often varchars are implemented as pascal strings: holding the actual length in the byte #0. The length was therefore bound to 255. (Value of a byte varies from 0 to 255.)
varchars 通常被实现为 pascal 字符串：在字节 #0 中保存实际长度。因此长度被绑定到 255。（一个字节的值从 0 到 255 不等。）
回答by Balaji Katika
<<
<<
Recollected the fundamentals of the bits/bytes storage, it requires one byte to store integers below 256 and two bytes for any integer between 256 and 65536. Hence, it requires same space (two bytes) to store 511 or 512 or for that matter 65535.... Thus it is clear that the this argument mentioned in the discussion above is N/A for varchar(512) or varchar(511).
回顾位/字节存储的基本原理，它需要一个字节来存储 256 以下的整数，而 256 和 65536 之间的任何整数需要两个字节。因此，它需要相同的空间（两个字节）来存储 511 或 512 或 65535 .... 因此很明显，上面讨论中提到的这个论点对于 varchar(512) 或 varchar(511) 是不适用的。
回答by gbn
8 bits unsigned = 256 bytes
8 位无符号 = 256 字节
255 characters + byte 0 for length
255 个字符 + 字节 0 表示长度
回答by Greg
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).
过去，所有字符串都需要一个 NUL 终止符，或“反斜杠零”。更新的数据库没有。它是“255 个文本字符”，在末尾自动添加了“\0”，因此系统知道字符串在哪里结束。如果你说 VARCHAR(256)，它最终会是 257，然后你会在一个字符的下一个寄存器中。浪费。这就是为什么一切都是 VARCHAR(255) 和 VARCHAR(31) 的原因。出于习惯，255 似乎一直存在，但 31 变成了 32，而 511 变成了 512。那部分很奇怪。很难让自己写 VARCHAR(256)。
