这将导致性能问题，尽管如果数据库较小，可能永远不会导致任何实际问题。每条记录将占用硬盘驱动器上更多的空间，如果您一次搜索大量记录，数据库将需要读取更多的磁盘扇区。例如，一个小的记录可以适合50个扇区，而一个大的记录可以适合5个扇区。如果使用大记录，则需要从磁盘读取10倍的数据。

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

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

如果一行中的所有数据(对于所有列)不会合理地占用8000或更少的字符，那么数据层的设计应该强制执行这一点。

数据库引擎可以更有效地将所有内容排除在blob存储之外。限制行越小越好。一页中可以塞进的行越多越好。当数据库必须访问更少的页面时，它的性能会更好。

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

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

一个问题是，如果你必须使用多个版本的SQL Server, MAX并不总是有效的。因此，如果您正在使用遗留DB或涉及多个版本的任何其他情况，您最好非常小心。

当你知道字段将在一个固定的范围内时，这不是一个好主意——例如5到10个字符。我想我只会在不确定长度的情况下使用max。例如，电话号码永远不会超过一定数量的字符。

你能诚实地说，你不确定表中每个字段的大约长度要求吗?

我确实明白你的意思——有些字段我肯定会考虑使用varchar(max)。

有趣的是，MSDN文档总结得很好:

的大小时使用varchar 列数据条目变化很大。 的大小时使用varchar(max) 列数据条目变化很大， 大小可能超过8000字节。

关于这个问题有一个有趣的讨论。