为什么历史上人们使用255而不是256用于数据库字段量级？

Question

您经常会看到数据库字段设置为255个字符,传统/历史原因是什么？我认为它与分页/内存限制和性能有关,但255和256之间的区别总是让我感到困惑.

varchar(255)

考虑到这是容量或幅度,而不是索引器,为什么255优先于256？是为某种目的保留的字节(终止符还是null或其他)？

推测varchar(0)是无意义的(零容量)？在这种情况下,2 ^ 8的空间应该是256？

是否有其他量级可以提供性能优势？例如,varchar(512)的性能低于varchar(511)或varchar(510)？

对于所有新旧关系数据库,此值是否相同？

免责声明 - 我是开发人员而不是DBA,我使用适合我的业务逻辑的字段大小和类型,但我想知道这种偏好的历史原因,即使它不再相关(甚至是更多,如果它仍然相关).

编辑:

感谢您的回答,似乎有一些共识认为一个字节用于存储大小,但这并不能在我的脑海中明确解决问题.

如果元数据(字符串长度)存储在相同的连续内存/磁盘中,则有一定意义.1个字节的元数据和255个字节的字符串数据非常适合彼此,并且适合256个连续的存储字节,这可能是整洁的.

但是......如果元数据(字符串长度)与实际字符串数据(可能在主表中)分开存储,那么将字符串数据的长度约束一个字节,只是因为它更容易只存储1个字节的整数元数据似乎有点奇怪.

在这两种情况下,它似乎都是一个微妙的可能取决于数据库的实现.使用255的做法似乎相当普遍,所以某个地方的人必须在一开始就为它辩护一个好的案例,有人能记住那个案例是什么吗？程序员在没有理由的情况下不会采用任何新的做法,这必须是新的一次.

Answer 1

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

长度为零的值肯定对varchar数据有效(除非另有约束).大多数系统将此类空字符串视为与NULL不同,但某些系统(尤其是Oracle)将空字符串视为与NULL完全相同.对于空字符串不为NULL的系统,将需要行中某处的附加位来指示该值是否应被视为NULL.

如您所知,这是历史优化,可能与当今的大多数系统无关.

Answer 2

255是mySQL4及更早版本中的varchar限制.

255个字符+ Null终结符= 256

或者1字节长度描述符给出可能的范围0-255个字符

Answer 3

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

Answer 4

来自MySQL手册:

数据类型:
VARCHAR(M),VARBINARY(M)

需要存储:
如果列值需要0 - 255字节,则为L + 1个字节;如果值可能需要超过255个字节,则为L + 2个字节

理解并做出选择.

Answer 5

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

Answer 6

最大长度为255允许数据库引擎仅使用1个字节来存储每个字段的长度.你是对的,1个字节的空间允许你为字符串的长度存储2 ^ 8 = 256个不同的值.

但是,如果允许该字段存储零长度文本字符串,则需要能够在长度中存储零.因此,您可以允许256个不同的长度值,从零开始:0-255.

Answer 7

过去，所有字符串都需要NUL终止符，或“反斜杠零”。更新后的数据库没有这个。它是“255 个字符的文本”，并在末尾自动添加“\0”，以便系统知道字符串在哪里结束。如果你说VARCHAR(256)，它最终会是 257，然后你会在下一个寄存器中输入一个字符。浪费。这就是为什么一切都是VARCHAR(255)和VARCHAR(31)。出于习惯，255 似乎一直存在，但 31 变成了 32，511 变成了 512。那部分很奇怪。让自己写作很难VARCHAR(256)。

Answer 8

varchars通常被实现为pascal字符串:将实际长度保存在字节#0中.因此长度绑定为255.(字节值从0到255之间变化.)

Answer 9

8 位无符号 = 256 字节

255 个字符 + 字节 0 表示长度

Answer 10

<<

重新收集了位/字节存储的基本原理,它需要一个字节来存储256以下的整数,并且需要两个字节来存储256到65536之间的任何整数.因此,它需要相同的空间(两个字节)来存储511或512或者就此而言65535 ....因此很明显,上面讨论中提到的这个论点是varchar(512)或varchar(511)的N/A.