FOR XML PATH 是 SQL Server 2005+ 兼容性最佳的多行字符串拼接方案，本质为行转字符串而非真 XML 构建，需配合 STUFF 去首分隔符，并用 TYPE + .value() 处理特殊字符以避免解析错误。
SQL Server 存储过程中用 FOR XML PATH 合并多行字符串
FOR XML PATH 是 SQL Server 2005+ 中最稳定、兼容性最好的多行拼接方案，尤其适合需要向下兼容到旧版本的存储过程。它本质是把结果集转成 XML 片段再剥掉标签，靠 STUFF 去掉开头多余分隔符。
常见错误现象：FOR XML PATH('') 返回类型是 xml，直接赋值给 varchar 变量会报错“无法将 xml 类型隐式转换为 varchar”；漏用 STUFF 导致结果开头多出逗号空格。
实操建议：
- 必须显式转换：用
CAST((SELECT ... FOR XML PATH('')) AS VARCHAR(MAX)) - 拼接前加前缀（如
', '+col），再用STUFF(..., 1, 2, '')删掉首段 - 字段含特殊字符（
、&）会被自动转义，需加TYPE和.value()处理，否则得到而非 - 在存储过程中声明变量时，目标字段务必用
VARCHAR(MAX)，别用VARCHAR(100)截断
SQL Server 2017+ 存储过程优先用 STRING_AGG
STRING_AGG 是专为此类需求设计的原生聚合函数，语义清晰、性能更好、无需 XML 转换开销。但它在存储过程中使用时，容易忽略排序和 NULL 处理这两个关键点。
常见错误现象：STRING_AGG(col, ',') 结果顺序随机；字段为 NULL 时整条记录被跳过（不是留空，是彻底不参与聚合）；在 WHERE 或 HAVING 中误用导致语法错误。
实操建议：
- 强制排序必须写在函数内：
STRING_AGG(col, ',') WITHIN GROUP (ORDER BY sort_col)，不能写在外部ORDER BY - 处理
NULL：先用ISNULL(col, '(null)')或COALESCE(col, '')包一层再进STRING_AGG - 分隔符为空字符串要写
SEPARATOR ''，不能省略或传NULL - 若需去重，
STRING_AGG不支持DISTINCT，得在外层用子查询或 CTE 先去重
存储过程里混用 FOR XML PATH 和 STRING_AGG 的兼容性陷阱
同一个存储过程既要跑在 SQL Server 2016（无 STRING_AGG）又要跑在 2022 上，不能简单用版本判断动态拼 SQL——因为语法树在编译阶段就校验，未执行到的分支也会报错。
常见错误现象：用 IF @@VERSION LIKE '%2017%' 包裹 STRING_AGG，结果在 2016 上编译失败，提示“'STRING_AGG' 附近有语法错误”。
实操建议：
- 放弃单存储过程兼容，拆成两个：一个用
FOR XML PATH（兼容 2005+），一个用STRING_AGG（标清最低版本注释） - 若必须统一，改用视图或表值函数封装拼接逻辑，在存储过程中只调用，避免编译期校验冲突
- 测试时别只看结果对不对，要抓
SET STATISTICS XML ON看实际执行计划——FOR XML PATH会产生额外的 XML 构建节点，大数据量下比STRING_AGG多 15–30% CPU 开销
为什么 GROUP_CONCAT 在 SQL Server 里根本不能用
看到 MySQL 教程里用 GROUP_CONCAT 就直接抄进 SQL Server 存储过程？会立刻报错 Invalid column name 'GROUP_CONCAT'。这不是拼写问题，是函数压根不存在。
常见误解：以为只是名字不同，换个函数名就行；或认为 SQL 标准里有这东西，各库只是实现差异。
实操建议：
- SQL Server 没有
GROUP_CONCAT，也没有LISTAGG（Oracle）、STRING_AGG（PostgreSQL）的旧版替代——FOR XML PATH就是事实标准 - 别依赖客户端工具（如 SSMS 插件或 Navicat）的“自动转换”功能，它们常把
GROUP_CONCAT错转成无效的CONCAT连接 - 如果从 MySQL 迁移过来，批量替换时注意：MySQL 的
SEPARATOR关键字在 SQL Server 里完全无效，必须整体重写逻辑
真正容易被忽略的是排序稳定性：FOR XML PATH 不带 ORDER BY 时结果顺序不可靠，而 STRING_AGG 不写 WITHIN GROUP 也一样——两者都不会默认按主键或插入顺序排，必须显式声明。
