为什么不使用varchar（max）？
在数据库devise方面，我有点老，所以我完全是在列中使用正确的数据大小。 但是，当为一个朋友查看数据库时，我注意到他使用了varchar(max) 。 现在，我的直接想法是把它扔回给他，让他改变它。 但是后来我想了一下，不能拿出一个很好的理由让他不要使用它（如果你想知道的话，他使用了一个casetypes的工具来生成数据库）。
我一直在研究varchar(max)用法的主题，我真的不能想出任何好的理由让他不要使用它。
他不使用索引列，坐在数据库上的应用程序对input有限制，所以不允许在字段中input大量数据。
任何帮助将不胜感激，帮助我让他看到光明:)。
我对此的回答不是关于Max的用法，而是关于VARCHAR（max）和TEXT的原因。
在我的书里 首先，除非你完全可以确定你永远不会编码除英文以外的任何东西，人们也不会引用外地的名字，那么你应该使用NVARCHAR或NTEXT。
其次，这是领域允许你做的。
与VARCHAR相比，TEXT很难更新，但是您将获得全文索引和许多聪明的东西。
另一方面，VARCHAR（MAX）有一些不明确的地方，如果单元格的大小<8000字符，它将被视为行数据。 如果更大，则将其视为存储目的的LOB。 因为在不查询RBAR的情况下无法知道这一点，所以对于需要确定数据的位置以及需要多less次读取的位置，可能会有优化策略。
否则，如果你的用法相对平淡无奇，而且你不希望遇到数据大小的问题（IE使用.Net，因此不必担心string/字符对象的大小）那么使用VARCHAR（max）很好。
有一篇关于为什么不在这里使用varchar max的博客文章
编辑
基本的区别在于数据的存储位置。 SQL数据行的最大大小为8000字节（或者是8K）。 然后一个2GB的varchar（max）不能被存储在数据行中。 SQL Server将其存储为“行外”。
因此，您可能会遇到性能问题，因为数据不在磁盘上的相同位置，请参阅： http : //msdn.microsoft.com/zh-cn/library/ms189087.aspx
如果您在OLTP环境中工作，那么您就是所有关于性能的东西。 从开销和调优问题到索引限制和查询瓶颈。 使用varcahr（max）或任何其他的LOBtypes很可能会违反大多数devise最佳实践，所以除非有特定的业务需求不能通过使用其他一些打字机制来处理，只有varchar（max）那么为什么还要让系统和应用程序受到其中一种LOB数据types固有的开销和性能问题的影响呢？
另一方面，如果您正在OLAP环境中工作，或者在具有描述符字段的维度表的星型模式DW环境中工作，那么这些描述符字段自然需要是冗长的，然后是varchar（max），只要您不将其添加到索引，可能是有用的。 即使如此，我仍然build议使用char（x）varchar（x）因为使用这些资源总是最佳实践，所以必须完成这项工作。
他们不应该被使用，除非你期望大量的数据，这就是为什么（直接从书籍在线）：
大对象（LOB）数据typesntext，text，varchar（max），nvarchar（max），varbinary（max），xml或image的列不能被指定为索引的关键字列。
如果你想削弱性能，使用nvarchar的一切。
我不知道如何从性能，内存和存储的angular度来看SQL Server如何处理大的（声明的）varchar字段。但是假设它和小声明的varchar字段一样高效，那么仍然有完整性约束的好处。
应用程序坐在数据库上应该有input限制，但如果应用程序有这方面的错误，数据库可以正确地报告错误。
差异在下：
VARCHAR(X)可以被索引并存储在MDF/NDF数据文件中。
VARCHAR(MAX)不能被索引，因为可以达到高音量，然后将被存储为一个单独的文件，而不是在MDF/NDF数据文件。
