据我所知，没有DBMS有任何“优化”可以使长度VARCHAR为a的2^n性能比max长度不是2的幂的性能更好。

我认为早期的SQL Server版本实际上将VARCHAR255的长度与最大长度较高的长度区别对待。我不知道是否仍然如此。

对于几乎所有的DBMS，所需的实际存储空间仅取决于您放入其中的字符数，而不取决于max您定义的长度。因此，从存储的角度（也可能是性能的角度），无论您将列声明为VARCHAR(100)还是都没有任何区别VARCHAR(500)。

您应该max将为VARCHAR列提供的长度看作是一种约束（或业务规则），而不是技术/实际的事物。

对于PostgreSQL来说，最好的设置是使用text不受长度限制CHECK CONSTRAINT的字符集，它将字符数限制为您的业务需求。

如果该要求发生变化，那么更改检查约束比更改表要快得多（因为不需要重写表）

可以对Oracle和其他对象应用相同的方法-在Oracle中，它VARCHAR(4000)不是，text而是。

我不知道SQL Server VARCHAR(max)和VARCHAR(500)SQL Server
之间是否存在物理存储差异。但是varchar(max)与相比，使用显然会对性能产生影响varchar(8000)。

看到此链接（由Erwin Brandstetter发表评论）

编辑2013-09-22

关于bigown的评论：

在9.2之前的Postgres版本中（我写初始答案时不可用），对列定义的更改 确实
重写了整个表，请参见例如此处。从9.2开始，情况不再如此，快速测试确认增加具有120万行的表的列大小实际上仅需0.5秒。

对于Oracle来说，从更改大表的varchar列所需的时间来看，这似乎也是正确的。但是我找不到任何参考。

对于MySQL，该手册会说 “ 在大多数情况下，ALTER TABLE为原始表创建一个临时副本
”。我自己的测试证实了：ALTER TABLE在具有120万行的表上运行（与我对Postgres的测试相同）以增加列的大小需要1.5分钟。但是，在MySQL中，您 不能
使用“替代方法”来使用检查约束来限制列中的字符数。

对于SQL Server，我找不到明确的声明，但是执行增加varchar列大小的执行时间（同样是上表的120万行表）表明 没有 重写。

编辑2017-01-24

似乎我（至少部分地）对SQL Server错误。请参阅Aaron
Bertrand的答案，该答案表明a
nvarchar或varcharcolumn 的声明长度对性能有很大的影响。