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

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

把它当做另一个安全等级。您可以设计没有外键关系的表(完全有效)，并确保完全在业务层上存在关联实体。然而，外键被认为是很好的设计实践，因为它们增加了另一个约束级别，以防业务层出现问题。同样，字段大小限制和不使用varchar 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

我有一个udf填充字符串，并把输出varchar(max)。如果直接使用它，而不是将其转换回正在调整的列的适当大小，则性能非常差。我最终将udf设置为一个任意长度的大音符，而不是依赖udf的所有调用者将字符串重新转换为较小的大小。

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

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

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