这是我的困境。

基本上，我需要一个表中的列来容纳未知长度的字符。 但是我很好奇，如果在Sql Server中使用列中的VARCHAR(MAX)或NVARCHAR(MAX)会出现性能问题，例如：'This time'我只需要存储3个字符，大多数时候我只需要 存储10个字符。 但是在该列中最多可能有几千个字符，甚至可能是一百万个字符，这是不可预测的。 但是，我可以保证它不会超过2GB的限制。

我只是好奇是否存在任何性能问题，或者可能存在解决此问题的更好方法。

在我看来，您打算将varchar(MAX)数据类型用于其预期用途。

当MAX数据类型中的数据超过8 KB时，将使用溢出页面。 SQL Server 2005自动为页面分配一个溢出指示器，并且知道如何像处理其他数据类型一样操作数据行。

要进一步阅读，请查看联机丛书：char和varchar

您不能在varchar(max)(和nvarchar(max))列上创建索引(尽管它们可以包含在其中。但是谁会在索引中包含可能达到2GB的列？！)，因此，如果要搜索此值，除非您使用全文本索引，否则每次都将进行扫描。另外，请记住，任何报表设计者或演示设计者(网络或其他)都必须假定有人可以将《百科全书》放到该专栏中并围绕它进行设计。没有比听到"用户可能不会做X"更糟糕的了。如果用户可以做到，他们就会做到。如果用户可以将tome放入列中，那么他们会在某个时候加入。如果他们从不应该，那就是IMO，将列的大小限制在一个合理的水平上是更有意义的，如果用户尝试在允许的列中填充更多内容，则会引发有关是否应在该值中输入值的讨论。该列放在首位。

我已经看到了一些问题-特别是标量函数(但是无论如何，它们通常都是可怕的)，它们返回varchar(MAX)，然后不进行重铸。例如，假设您有一个特殊函数CleanString(somevarcharmax)返回varchar(max)并在varchar(50)上调用它，但不要CAST(CleanString(varchar10col)AS varchar(10))-讨厌的性能问题。

但是通常，当您在表中有varchar(max)列时，您不应该批量执行这些类型的操作，所以我想说，如果您针对表中的数据需求正确使用了它，那很好。

我前几天刚看过这篇文章。它记录了varchar(max)在varchar(n)列上的性能滞后。可能不足以为您带来改变。但是，如果这样做的话，也许您可??以使用一个单独的表来存储那几个大文本块。您的小文本可以保留在主表中，但是您可以添加一个标志字段，告诉您在新表中查找大文本。

Crystal Reports 12(据我所知，以及其他版本)不能正确处理varchar(max)，并将其解释为varchar(255)，这会导致报表中的数据被截断。

因此，如果您使用的是Crystal Reports，那对varchar(max)来说是一个缺点。确切地说，还是使用Crystal的缺点。

看到：
http://www.crystalreportsbook.com/Forum/forum_posts.asp?TID=5843&PID=17503
http://michaeltbeeitprof.blogspot.com/2010/05/crystal-xi-and-varcharmax-aka-memo.html

不，varchar(max)会根据条目的大小进行自我调整，因此，如果您要使用大小不同的输入，这将是最有效的。