任何隐藏的陷阱将列从varchar（8000）更改为varchar（max）？

Question

我有很多（超过一千个地方）遗留T-SQL代码，只会将INSERT放入实用程序表中的varchar(8000)列。我们的需求已经改变，现在该列需要能够处理更大的值。因此，我需要制作该列varchar(max)。这只是一个普通的数据列，其中没有执行搜索，没有索引，只有一个过程读取它，它是INSERT并且忘记了应用程序（几乎就像一个日志条目）。

我计划仅在几个实际生成较大数据的地方进行更改，并在处理此列的单个存储过程中进行更改。

• 是否有任何隐藏的陷阱将列从varchar(8000)更改为varchar(max)？
• 所有T-SQL字符串函数是否都有效，LEN()，RTRIM()，SUBSTRING()等。
• 任何人都可以想象为什么我必须对认为列仍然是varchar(8000)的代码进行任何更改？

Answer 1

• 所有MAX类型的性能损失都很小，请参阅Performance comparison of varchar(max) vs. varchar(N)。
• 如果您的维护包括在线操作（在线索引重建），您将无法执行这些操作。 Online operations are not supported for tables with BLOB columns：

    

    
  • 当基础表包含大对象（LOB）数据类型时，必须创建，重建或删除脱机的聚簇索引：image，ntext，text，varchar（max），nvarchar（max）， varbinary（max）和xml。
    
  • 当表包含LOB数据类型时，可以在线创建非唯一非聚簇索引，但这些列中没有一列在索引定义中用作键或非键（包含）列。必须在脱机时创建或重建使用LOB数据类型列定义的非聚簇索引。
    

性能损失真的小，所以我不担心。对于真正热门的必须在线操作表而言，失去进行在线重建的能力可能会有问题。除非必须进行在线操作，否则我会投票支持并将其更改为MAX。

Answer 2

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

Answer 3

如果你真的不需要索引而且它是一个很大的列你应该没问题。 Varchar（max）似乎正是您所需要的，现有代码的问题比使用文本时要少。

确保测试将文本添加到现有文本的任何更新。它应该使用常规连接，但我希望能够证明它。