STRING_AGG溢出主因是返回类型推导过短而非数据量大，需用CONVERT(NVARCHAR(MAX), STRING_AGG(...))显式指定长类型，并确保兼容级别≥150以启用优化推导。
STRING_AGG 溢出不是数据量太大，而是结果字符串超长且目标类型推导为 varchar 或 nvarchar 短长度类型，导致隐式截断或转换失败。
溢出错误的典型现象和触发条件
常见报错信息是：String or binary data would be truncated 或 Arithmetic overflow error converting expression to data type varchar。这不是内存溢出，而是 SQL Server 在推导 STRING_AGG 返回类型时，按输入列最大长度（如 varchar(50)）乘以行数粗略估算，再套用内部上限规则，最终可能生成一个远小于实际需要的 varchar(n) 类型——一旦拼接后总长超过该 n，就直接报错。
- 源列是
varchar(10)，但分组有 200 行 → SQL Server 可能推导返回类型为varchar(2000)，而实际拼接含分隔符后达 2500 字符 - 混用不同长度字符串：比如
STRING_AGG(ISNULL(name, ''), ', ')中，ISNULL(name, '')继承name的类型（varchar(20)），但空字符串字面量是varchar(1)，类型推导混乱 - 嵌套表达式未显式转长类型：如
STRING_AGG(UPPER(last_name), ', ')，UPPER不改变原长度声明，仍按last_name的varchar(x)推导
必须显式指定返回类型长度
SQL Server 不允许直接写 STRING_AGG(...) 后加 AS VARCHAR(MAX)，但可通过 CONVERT 或 CAST 强制提升目标类型。这是最稳定、最可控的解法。
- 正确写法：
CONVERT(NVARCHAR(MAX), STRING_AGG(name, ', ')) - 若源列为
varchar且确定无 Unicode 数据，可用CONVERT(VARCHAR(MAX), STRING_AGG(name, ', ')) - 避免只对参数转类型：
STRING_AGG(CONVERT(NVARCHAR(MAX), name), ', ')无效——类型推导仍基于聚合逻辑，不解决结果截断 - 在视图或函数中尤其要固化此写法，否则下游调用可能因上下文类型推导差异再次溢出
WHERE 过滤和 NULL 处理不当会加剧溢出风险
看起来无关的操作，实际会让类型推导更悲观。例如，用 COALESCE(name, 'N/A') 替换 NULL 时，如果 name 是 varchar(5)，'N/A' 是 varchar(3)，SQL Server 会取两者最大长度（5），再乘以预估行数——但真实拼接中每个 'N/A' 实际占 3 字符，而系统仍按 5 算，容易误判溢出。
- 优先用
ISNULL(name, '')：它保持左侧类型，且空字符串字面量会被统一视为与左侧同类型、长度为 0 的值，推导更准 - 提前过滤无效值：
WHERE name IS NOT NULL AND LEN(name) > 0，减少参与聚合的行数，降低推导上限 - 若业务允许，把超长字段单独提取、限制长度再拼接：
STRING_AGG(LEFT(description, 100), ' | ')
兼容级别和版本影响类型推导行为
SQL Server 2019（CU15+）对 STRING_AGG 返回类型推导做了优化，但前提是数据库兼容级别 ≥ 150。若仍为 140（2017 默认）或更低，推导逻辑更保守，更容易触发溢出错误。
- 查当前级别：
SELECT DATABASEPROPERTYEX(DB_NAME(), 'CompatibilityLevel') - 升级兼容级别：
ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 150 - 注意：升级前需测试，某些旧语法（如某些隐式转换）可能失效
- 即使版本是 2019，若兼容级别卡在 120（2014），
STRING_AGG本身都不可用；130（2016）则虽可用但推导逻辑未更新
真正麻烦的不是拼得长，而是 SQL Server 在没看到 CONVERT(...MAX...) 时，根本不会去算“到底要多长”，它只按旧规则拍一个数——这个数经常不够用，而且你很难从执行计划里提前发现。
