据我所知，没有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
为原始表创建一个临时副本
”。我自己的测试证实了：
ALTERTABLE在具有120万行的表上运行（与我对Postgres的测试相同）以增加列的大小需要1.5分钟。但是，在MySQL中，您 不能
使用“替代方法”来使用检查约束来限制列中的字符数。
对于SQL Server，我找不到明确的声明，但是执行增加
varchar列大小的执行时间（同样是上表的120万行表）表明 没有 重写。
编辑2017-01-24
似乎我（至少部分地）对SQL Server错误。请参阅Aaron
Bertrand的答案，该答案表明a
nvarchar或
varcharcolumn 的声明长度对性能有很大的影响。
