将列从 varchar(8000) 更改为 varchar(max) 是否存在任何隐藏的陷阱？

我有很多（超过一千个地方）的遗产T-SQL代码只使INSERT变成一个varchar(8000)实用程序表中的列。我们的需求发生了变化，现在该列需要能够处理更大的值。结果我需要制作该专栏varchar(max)。这只是一个纯数据列，没有对其执行搜索，没有索引，只有一个过程读取它，它是INSERT并忘记应用程序（几乎就像日志条目）。

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

• 更改列是否存在任何隐藏的陷阱varchar(8000) to a varchar(max)?
• 会不会所有的T-SQL字符串函数的工作原理相同，LEN(), RTRIM(), SUBSTRING(), etc.
• 谁能想象为什么我必须对认为该列仍然存在的代码进行任何更改varchar(8000)?

• Allmax 类型有较小的性能损失，请参阅varchar(max) 与 varchar(N) 的性能比较 http://rusanu.com/2010/03/22/performance-comparison-of-varcharmax-vs-varcharn/.
• If your maintenance include online operations (online index rebuild), you will lose the possibility to do them. Online operations are not supported for tables with BLOB columns http://msdn.microsoft.com/en-us/library/ms190981.aspx:

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

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