如上所述，这主要是存储和性能之间的权衡。至少在大多数情况下是这样。

然而，在选择n/varchar(Max)而不是n/varchar(n)时，至少还有一个其他因素需要考虑。数据是否将被索引(例如，一个姓氏)?因为MAX定义被认为是LOB，所以任何定义为MAX的东西都不能用于索引。如果没有索引，在WHERE子句中涉及数据作为谓词的任何查找都将被迫进行全表扫描，这是您可以获得的数据查找的最差性能。

我发现的唯一问题是我们在SQL Server 2005上开发应用程序，在一个实例中，我们必须支持SQL Server 2000。我刚刚知道，SQL Server 2000不喜欢varchar或nvarchar的MAX选项。

这是一个公平的问题，他除了明显的……

缺点包括:

性能影响 查询优化器使用字段大小来确定最有效的执行计划

“1。数据库扩展和页面的空间分配是灵活的。因此，当使用update向字段添加信息时，如果新数据比之前插入的数据长，数据库就必须创建一个指针。这样，数据库文件将变得碎片化=从索引到删除、更新和插入，几乎所有方面的性能都较低。” http://sqlblogcasts.com/blogs/simons/archive/2006/02/28/Why-use-anything-but-varchar_2800_max_2900_.aspx

集成影响——其他系统很难知道如何与您的数据库集成 不可预测的数据增长 可能的安全问题，例如占用所有磁盘空间可能导致系统崩溃

这里有一篇好文章: http://searchsqlserver.techtarget.com/tip/1,289483,sid87_gci1098157,00.html

有趣的链接:当你可以使用文本时，为什么要使用VARCHAR ?

它是关于PostgreSQL和MySQL的，所以性能分析是不同的，但是“显式”的逻辑仍然成立:为什么强迫自己总是担心一些在一小部分时间内相关的事情呢?如果你把一个电子邮件地址保存到一个变量中，你会使用一个“字符串”而不是一个“限制为80个字符的字符串”。

同样的问题也出现在MSDN论坛上:

Varchar(max) vs Varchar(255)

原文(更多信息):

When you store data to a VARCHAR(N) column, the values are physically stored in the same way. But when you store it to a VARCHAR(MAX) column, behind the screen the data is handled as a TEXT value. So there is some additional processing needed when dealing with a VARCHAR(MAX) value. (only if the size exceeds 8000) VARCHAR(MAX) or NVARCHAR(MAX) is considered as a 'large value type'. Large value types are usually stored 'out of row'. It means that the data row will have a pointer to another location where the 'large value' is stored...

数据库的任务是存储数据，以供企业使用。让数据有用的一部分是确保它是有意义的。允许用户为自己的名字输入无限个字符并不能确保数据有意义。

将这些约束构建到业务层是一个好主意，但这并不能确保数据库保持完整。保证数据规则不被违反的唯一方法是在数据库中尽可能低的级别执行它们。