SQL Server 无 LISTAGG 函数，报错源于方言混淆；2017+ 应用 STRING_AGG 并显式 CAST 输入为 NVARCHAR(MAX)，避免隐式类型退化导致截断。
SQL Server 根本没有 LISTAGG 函数，所以你看到的“超出 LISTAGG 长度限制”错误，一定是误配了数据库方言、客户端自动转换，或者开发人员在 SQL Server 环境里写了 Oracle/PostgreSQL 语法并期望它运行。
SQL Server 报错 “LISTAGG” 是典型方言混淆
SQL Server 自 2017 起才提供原生字符串聚合函数 STRING_AGG；此前只能靠 FOR XML PATH('') 或自定义聚合函数模拟。如果你在 SQL Server 中直接写 LISTAGG(col, ',')，会收到类似以下错误：
Msg 195, Level 15, State 10, Line X<br>‘LISTAGG’ is not a recognized built-in function name.
——但有些 ORM（如旧版 MyBatis）、BI 工具（如 Tableau 连接 Oracle 模式后切到 SQL Server）或开发人员手动粘贴脚本时，没改函数名，导致报错被误读为“长度超限”。
- 确认执行环境：用
SELECT @@VERSION查看是否真为 SQL Server - 检查实际执行的 SQL：捕获真实发送到服务器的语句，而非编辑器里写的“伪代码”
- 注意客户端驱动行为：某些 JDBC/ODBC 驱动在连接串中指定
Oracle模式后，会尝试转译函数名，结果转出无效 SQL
SQL Server 的 STRING_AGG 真实长度限制在哪？
STRING_AGG 默认返回 varchar(max) 或 nvarchar(max)，理论上限 2GB，**不会因拼接长度直接报“超限”错误**。但实际触发截断或失败，通常源于以下三处：
- 目标列类型不匹配：比如把
STRING_AGG结果 INSERT 进varchar(4000)字段，插入时被静默截断，而非聚合时报错 - 隐式转换丢失 max：若参与拼接的列是
varchar(8000)，而未显式转成varchar(max)，STRING_AGG可能退化为非 max 类型，最终受限于 8000 字节 - 排序字段含不可比类型：如对
xml、text（已弃用）、ntext列ORDER BY，会触发Msg 306，被误认为“聚合失败”
验证方式：SELECT DATALENGTH(STRING_AGG(content, ',')) FROM t —— 若返回值接近 8000，大概率是中间某列没 cast 成 max。
FOR XML PATH('') 方式为什么常“看似超长”？
这是 SQL Server 2016 之前最常用的模拟方案，典型写法：
SELECT STUFF((SELECT ',' + name FROM t FOR XML PATH(''), TYPE).value('.', 'NVARCHAR(MAX)'), 1, 1, '')
它出问题不是因为“聚合长度限制”，而是：
-
FOR XML默认将特殊字符（<,&,"）转义为实体（），导致输出膨胀，表面看“变长了” - 漏写
TYPE和.value()：不加TYPE会返回varchar而非xml，再调.value()时可能截断；不加.value()则结果带 XML 标签 - 源列含 NULL：未用
ISNULL(name, '')包裹，会导致整段拼接结果为 NULL
该用哪个方案？别只看“能不能跑”
SQL Server 2017+ 强烈优先用 STRING_AGG，但必须注意类型显式性：
- 确保所有输入列都转成
varchar(max)或nvarchar(max)，例如：STRING_AGG(CAST(name AS NVARCHAR(MAX)), ', ') WITHIN GROUP (ORDER BY id) - 避免在子查询或 CTE 中先聚合再 CAST —— 类型推导可能失效，应在
STRING_AGG内部就完成转换 - 如果仍需兼容老版本，
FOR XML PATH('')必须带TYPE+.value()+STUFF三件套，缺一不可
真正容易被忽略的是：SQL Server 的“长度问题”几乎从不发生在聚合函数本身，而总藏在类型推导链的某个隐式环节里——查 sys.dm_exec_describe_first_result_set 看实际返回类型，比猜报错原因快得多。
