是否有任何理由使用VARCHAR大小四舍五入为128/256/4096字节偏移量？

在数据库模式中，我经常注意到VARCHAR的大小四舍五入为字节偏移量128/256或4096。我之前也做过，其背后的想法可能是高效的。

但是，如今仍然有这样做的正当理由吗？这些天，我经常使用'50'，'100'或'200'作为VARCHAR大小，因为它们比较自然，通常还会在验证检查中显示给用户。

我能想到的唯一合理的解释是：如果DBMS按顺序存储一列的值，并且大小未四舍五入为2的幂，则可能必须将某些元素“拆分”为硬页上的两页驱动器（例如，第n页中的前10个字节和第n + 1页中的后40个字节），在某些情况下可能导致从硬盘读取两次而不是一次。

@Jan Hudec的观点更可能是，许多程序员将“ 128”或“ 256”视为“ nice round number”，这使它们成为比137、19或100等奇数更为自然的选择。

通常，没有理由使用这些列长度。与varchar（128）列相比，varchar（100）列的性能不会得到改善。

但是，我将再次检查您使用的数据库系统，以进一步阐明限制和其他特定于供应商的警告。

例如，这是SQL Server数据库系统限制的一个很好的例子：

http://msdn.microsoft.com/en-us/library/ms186981.aspx

行的总长度比单个列的长度更重要。

我不记得它是DBMS还是编译器，但我确实记得（很久以前）学习对数组和列的长度使用2的幂。有理由认为它是“更快的”，因为该实现可以使用位移。是否成立真的是一个悬而未决的问题。有人对它是否仍然有效有任何想法吗？

顺便说一句，我已经将列宽移动到统一数字b / c，告诉用户char限制为256个chars很奇怪。

而且一些非常古老的数据库确实将您限制为256个字符宽度的列。

这可能并不重要，因为如果整个行的大小恰好是2的幂，那么您实际上只会看到一定的存储效率。坚持2的幂可能会使您的行大小更有可能可以计算出2的幂（因为大多数本机数据类型往往是2的幂（取决于数据库）），但是我不会把它定为一成不变的规则。

如果使用大（4K或更大）列，则可能更有意义，因为它们可以单独存储，并调整大小以使其适合一个存储块（无论数据库用于磁盘存储的内容）你的东西。

虽然我并不熟悉所有的DBMS系统，但是Oracle中最小的“物理”存储单元是“块”，默认情况下大小为2KB。将列按2的幂进行大小调整的做法是将行按大小适当调整以适合存储块的较大做法的一部分。调整列的大小，以便一行将比块大小多分配一个字节，这将需要分配两个块，并且行还将跨越两个块，这使得读取，插入和扫描所花费的时间比每个行都适合一个块（并且每个块中只有一行）。至少，这是历史原因。如今，大多数人认为这种做法是次优化的。