我所知道的任何 DBMS 都没有任何“优化”，可以使长度比VARCHAR长度不是 2 的幂的更好。2^n``max

我认为早期的 SQL Server 版本实际上对VARCHAR长度为 255 的 a 的处理方式与对最大长度的处理方式不同。我不知道现在是否仍然如此。

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

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

对于 PostgreSQL，最好的设置是使用text没有长度限制，并且将CHECK CONSTRAINT字符数限制为您的业务需要的任何字符。

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

这同样适用于甲骨文和其他人——在甲骨文中它会VARCHAR(4000)代替text。

我不知道 SQL Server
之间是否存在物理存储VARCHAR(max)差异VARCHAR(500)。但显然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
的这个答案，这表明声明的
anvarchar或varchar列的长度对性能有很大的影响。