许多数据库模式似乎遵循以下标准：
大字段的（2 ^ n）-1 ：
varchar(511)
varchar(255)
varchar(127)
...然后（2 ^ n）表示较小的
varchar(64)
varchar(32)
varchar(16)
varchar(8)
我理解为什么使用（2 ^ n）-1的数字，我不明白为什么没有必要将趋势继续到小字段。
E.g。
varchar(63)
varchar(31)
varchar(15)
varchar(7)
这是否有原因，或者只是回报已经减少太多了？
答案 0 :(得分：7)
我认为只是程序员在没有真正重要的情况下从空中挑选一些数字。
如果您必须对“注释”字段设置限制，例如非程序员可能会选择100或200个字符作为一个整数，而程序员可能会将127或255视为一个整数。
答案 1 :(得分：5)
我记得过去的时候，当使用2 ^ n长度时，磁盘或内存上的块对齐更好。 对齐块更快。 今天“Block”尺寸更大，内存和磁盘速度足以忽略对齐， 对于那些非常大的块来说（无论“非常大”意味着什么......）
现在这样做很传统。
另一个原因是我的名言： 只有10种人：可以使用二元和其他人。
2 ^ n -1是mersenne primes的候选者。所以它也很怪异......
答案 2 :(得分：3)
我不能说因为我看到“-1”趋势对于较小/较大的字段使用不同。但是我认为它只不过是developer / dba OCD。当他们真的应该根据业务规则做出字段长度决定而不是“漂亮”时，总是想要“圆”数字
答案 3 :(得分：2)
不仅减少了回报，而且如果你设置了具有任意限制的字符串类型，那么你解决问题的可能性要大得多。
如果它确实是业务约束，那么在长度上使用TEXT类型（或类似）和CHECK约束，并根据您尝试强制执行的业务约束选择数字。
无论如何，DBMS可能会以相同的varchar（x）实现TEXT类型的存储。如果没有，而且你真的在乎，你应该调查你的特定系统的内部存储策略，并考虑是否对varchar有任何好处。
答案 4 :(得分：0)
实际上，这是我第一次听说这种“趋势”。我的varchar-field总是和我需要它们一样长。
我会说它背后没有特别的原因。只是开发人员的偏好。
答案 5 :(得分：0)
我无法想象他们为什么要计算那些在2 ^ N或2 ^ N-1计数上的字段。从SQL Server的角度来看，这听起来更像是对SQL如何在页面级别存储数据的误解，而不是特定原因。
我会更加关注类型，潜在的页面外存储（SLoB / LoB）和行/页面+满足业务需求的大小，而不是基于使用2 ^ N等的公式