每次建立一个新的SQL表或向现有表添加一个新的varchar列时，我都想知道一件事:长度的最佳值是多少。
假设，你有一个列名为name类型为varchar。所以，你必须选择长度。我想不出一个20个字符的名字，但你永远不会知道。但不是用20，我总是四舍五入到下一个2^n。在这种情况下，我将选择32作为长度。我这样做，是因为从计算机科学家的角度来看，2^n这个数字在我看来比其他数字更均匀，我只是假设下面的架构可以比其他数字更好地处理这些数字。
另一方面，以MSSQL服务器为例，当您选择创建varchar列时，将默认长度值设置为50。这让我开始思考。为什么50 ?它只是一个随机数，还是基于平均列长，还是什么?
也可能是——或者可能是——不同的SQL服务器实现(如MySQL, MSSQL, Postgres，…)有不同的最佳列长度值。
当前回答
经常向您的业务领域专家咨询。如果你是这样，那就寻找一个行业标准。例如，如果所讨论的域名是一个自然人的姓氏，那么对于一家英国企业，我会去英国政府谈话数据标准目录查找个人信息，并发现一个姓氏将在1到35个字符之间。
其他回答
最佳值是基础域中定义的数据的正确值。
对于某些域，VARCHAR(10)适合Name属性，对于其他域，VARCHAR(255)可能是最佳选择。
I haven't checked this lately, but I know in the past with Oracle that the JDBC driver would reserve a chunk of memory during query execution to hold the result set coming back. The size of the memory chunk is dependent on the column definitions and the fetch size. So the length of the varchar2 columns affects how much memory is reserved. This caused serious performance issues for me years ago as we always used varchar2(4000) (the max at the time) and garbage collection was much less efficient than it is today.
VARCHAR(255)和VARCHAR(2)在磁盘上占用的空间完全相同!所以限制它的唯一原因是如果你有特定的需要让它更小。否则都设为255。
具体来说，在进行排序时，较大的列确实会占用更多的空间，因此如果这会影响性能，那么您需要担心它，并将其减小。但如果你只从表中选择了一行，那么你可以把它们都设为255，这没有关系。
参见:MySQL的最佳varchar大小是多少?
在某种意义上你是对的，尽管任何低于2^8个字符的数据仍然会被注册为一个字节。
如果您将留下VARCHAR < 255的任何内容的基字符视为消耗相同数量的空间。
255是一个很好的基线定义，除非您特别希望减少过多的输入。
我所知道的DBMS中没有任何“优化”可以使长度为2^n的VARCHAR比最大长度不是2的VARCHAR性能更好。
我认为早期的SQL Server版本实际上对待长度为255的VARCHAR与最大长度更高的VARCHAR是不同的。我不知道现在是不是还是这样。
对于几乎所有的DBMS，实际需要的存储空间仅由您放入其中的字符数决定，而不是您定义的最大长度。因此，从存储的角度(很可能也是性能的角度)来看，将列声明为VARCHAR(100)还是VARCHAR(500)没有任何区别。
您应该看到为VARCHAR列提供的最大长度是一种约束(或业务规则)，而不是技术/物理方面的东西。
对于PostgreSQL，最好的设置是使用没有长度限制和CHECK约束的文本，CHECK约束限制了您的业务所需的字符数量。
如果需求发生变化，更改检查约束比更改表要快得多(因为表不需要重写)。
同样的方法也适用于Oracle和其他应用程序——在Oracle中，它将是VARCHAR(4000)而不是文本。
我不知道在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对原始表进行临时复制”。我自己的测试也证实了这一点:在一个有120万行的表上运行一个ALTER TABLE(与我使用Postgres进行的测试相同)来增加一个列的大小需要1.5分钟。然而，在MySQL中，你不能使用“变通方法”来使用检查约束来限制列中的字符数。
对于SQL Server，我找不到一条明确的语句，但增加varchar列大小的执行时间(同样是上面的120万行表)表明没有发生重写。
编辑2017-01-24
看来我对SQL Server的看法(至少部分)是错误的。Aaron Bertrand给出的答案表明，nvarchar或varchar列的声明长度对性能有很大影响。
