SQL Server 存储过程中不能用 VARCHAR(MAX) 当作 LOB 流处理容器，它只是大字符串类型；真要流式读写（比如边解密边写入、分块压缩），必须用 SqlBytes 或 SqlChars 在 CLR 环境中实现。
直接说结论：SQL Server 存储过程中不能用 VARCHAR(MAX) 当作 LOB 流处理容器，它只是大字符串类型；真要流式读写（比如边解密边写入、分块压缩），必须用 SqlBytes 或 SqlChars 在 CLR 环境中实现。
为什么 VARCHAR(MAX) 不等于 LOB 流处理
VARCHAR(MAX) 是 SQL Server 对 CLOB 的逻辑替代，最大支持 2GB 字符数据，但它在存储过程内部仍按“完整值”加载——哪怕你只查前 100 字符，整个值也得先从磁盘读进内存再截取。这会导致：
- 内存峰值陡增，尤其在并发场景下容易触发
OutOfMemoryException - 无法对超大值做增量处理（比如逐块 Base64 解码后写入 BLOB）
- 所有字符串函数（
SUBSTRING、REPLACE）都要求整值加载，无流式 API
SqlBytes 和 SqlChars 才是真正的流接口
它们专为 CLR 集成设计，允许你在 .NET 代码里以 Stream 方式操作 LOB 数据，数据库只传定位器（LOB locator），不搬数据本身：
-
SqlBytes对应VARBINARY(MAX)，暴露Stream属性，可Read()/Write()分块 -
SqlChars对应NVARCHAR(MAX)，提供GetBuffer()和Length，适合逐段解析文本 - 二者都支持
IsNull属性判断空值，比IS NULL更准（区分 NULL 和 empty）
示例片段（C# CLR 函数）：
public static SqlBytes ProcessBlob(SqlBytes input)
{
if (input.IsNull) return input;
using (var stream = input.Stream)
{
// 这里可以边读边转码，不全载入内存
var buffer = new byte[8192];
int read;
while ((read = stream.Read(buffer, 0, buffer.Length)) > 0)
{
// 处理 buffer[0..read-1]
}
}
return input;
}Oracle/MySQL 用户别套用这套逻辑
SQL Server 的 SqlBytes 机制是 CLR 特有，Oracle 用 DBMS_LOB 包（如 DBMS_LOB.WRITEAPPEND）、MySQL 用 LOAD_FILE() 或客户端分片上传，三者底层模型完全不同：
- Oracle 的
EMPTY_BLOB()+SELECT ... FOR UPDATE+DBMS_LOB.WRITE是指针+分块写，但必须在 PL/SQL 块内完成 - MySQL 的
LONGBLOB没有原生分块 API，LOAD_FILE()要求文件在服务器本地且权限开放，实际常用应用层分片 - SQL Server 若强行在 T-SQL 里模拟“流”，只能靠
TEXT类型的过时READTEXT/WRITETEXT（已弃用），或拆成多行VARBINARY(8000)手动拼接——极其脆弱
真正容易被忽略的点是：LOB 流处理从来不是纯 SQL 层能力，它必然绑定具体数据库的扩展机制（CLR / DBMS_LOB / 应用驱动层）。选错抽象层，比如试图用 T-SQL 函数去“流式解析 PDF”，结果只会是超时或 OOM。
