为什么 SQL 字段长度总是 (2^n)-1，除非小于 127？答案

【问题标题】：Why are SQL fields lengths always (2^n)-1 unless less than 127?为什么 SQL 字段长度总是 (2^n)-1，除非小于 127？
【发布时间】：2019-05-21 18:15:59
【问题描述】：

很多数据库模式似乎都遵循以下标准：

(2^n)-1 用于大字段：

varchar(511)
varchar(255)
varchar(127)

...然后 (2^n) 用于较小的

varchar(64)
varchar(32)
varchar(16)
varchar(8)

我明白为什么使用 (2^n)-1 的数字，我不明白的是为什么没有必要将趋势延续到小字段。

例如

varchar(63)
varchar(31)
varchar(15)
varchar(7)

这是有原因的还是只是回报减少得太多了？

【问题讨论】：

【解决方案1】：

我记得以前，当使用 2^n 长度更好地对齐磁盘或内存上的块时。对齐的块更快。今天“块”大小更大，内存和磁盘足够快，可以忽略对齐，除了非常大的块之外。（无论“非常大”在今天是什么意思......）

如今，这样做只是传统。

还有一个我成为名言的原因：只有10种人：会二进制的人和其他人。

并且 2^n -1 是梅森素数的候选者。所以它也很怪异......

【讨论】：

对于 2^n -1 问题：许多编程语言使用空字节来终止字符串值（Pascal 不是这样，但将长度存储在字符串的第一个字节），所以你需要多一个字节来存储字符串。所以这也可能是少用一个的原因。

【解决方案2】：

我认为这只是程序员在无关紧要时从空中挑选一个数字。

如果您必须对“注释”字段进行限制，例如，非程序员可能会选择 100 或 200 个字符作为整数，而程序员可能会将 127 或 255 视为整数。

【讨论】：

【解决方案3】：

我不能说，因为我已经看到“-1”趋势在较小/较大字段中的使用方式不同。但是我认为这只不过是开发人员/dba 强迫症。当他们真的应该根据业务规则而不是“漂亮”来决定字段长度时，他们总是想要“整数”

【讨论】：

【解决方案4】：

不仅回报减少了，而且如果您将字符串类型设置为任意限制，您更有可能导致问题而不是解决问题。

如果确实是业务约束，则使用 TEXT 类型（或类似类型）和 CHECK 长度约束，并根据您要强制执行的业务约束选择数字。

无论如何，DBMS 可能会以与 varchar(x) 相同的方式实现 TEXT 类型的存储。如果没有，而且您真的很在意，您应该调查特定系统的内部存储策略，并考虑 varchar 是否有任何好处。

【讨论】：

【解决方案5】：

其实我还是第一次听说这样的“趋势”。我的 varchar 字段总是只要我需要它们。

我想说这背后没有什么特别的原因。只是开发者的偏好。

【讨论】：

【解决方案6】：

我一时无法想象他们为什么要以 2^N 或 2^N-1 的方式来调整字段的大小。从 SQL Server 的角度来看，这听起来更像是对 SQL 如何在页面级别存储数据的误解，而不是具体原因。

与基于使用 2^N 等的公式相比，我会更关注类型、潜在的页外存储 (SLoB / LoB) 和行/页 + 满足业务需求的大小调整

【讨论】：