简介这份PDF资料聚焦SQL Server中字符串聚合的实用技巧面向数据库开发与运维人员尤其是仍在使用SQL Server 2017之前版本、需要将同组多行字符串合并为单列输出的开发者。内容以AggregationTable示例表为线索演示如何通过自定义T-SQL函数AggregateString把相同Id下的Name字段拼接成“赵孙李”“钱周”这类结果弥补SUM、AVG、COUNT、MAX、MIN等数值聚合函数无法处理字符串的短板并顺带对比了STRING_AGG内置函数的替代思路。资源包共1个PDF文件约35KB轻量易读适合快速查阅与收藏。目前已有3509人学习下载说明该问题在实际开发中较为常见。读者可从中掌握自定义字符串聚合函数的完整写法、调用方式与分组查询配合技巧并理解SELECT、字符串函数、聚合函数等核心概念在真实场景中的组合运用为处理类似字符串合并需求提供可直接参考的解决路径。1. 字符串聚合这件事为什么在 SQL Server 里总让人卡壳如果你是从 MySQL 的GROUP_CONCAT或者 PostgreSQL 的string_agg转过来的第一次在 SQL Server 里想「把分组后的多行拼成一个字符串」大概率会愣一下——翻遍函数列表找不到一个叫GROUP_CONCAT的东西。这不是你记错了而是 SQL Server 在很长一段时间里确实没有原生的字符串聚合函数。老版本里大家靠FOR XML PATH这种「曲线救国」的写法硬凑代码又长又难读遇到特殊字符还会翻车。直到 SQL Server 2017 才正式引入STRING_AGG才算把这个坑填上。这篇笔记就围绕「SQL Server 字符串聚合函数」这个主题把老写法和新函数的差异、STRING_AGG的参数怎么调、排序和去重怎么处理、以及实际迁移时踩过的坑一条条讲清楚。适合正在做报表拼接、订单明细合并、标签汇总这类需求的开发和 DBA也适合手上还跑着 SQL Server 2008 R2、暂时升不了级、只能继续用老办法的人。2. STRING_AGG 到底怎么用从语法到第一个能跑的例子2.1 先搞清楚它解决的是什么问题字符串聚合的核心场景是把「一对多」的数据压成「一行一列」。比如一张订单明细表一个订单号对应多条商品记录你想在报表里显示成「苹果,香蕉,橙子」这样一行。用普通的GROUP BY只能得到分组没法把组内的字符串拼起来。STRING_AGG就是干这个的它是个聚合函数跟SUM、COUNT一样参与GROUP BY只不过它累加的是字符串中间用你指定的分隔符连接。它的基本签名是STRING_AGG ( expression, separator )expression是要拼接的列或表达式separator是分隔符可以是逗号、分号、竖线甚至多字符。注意expression在拼接前会被隐式转换成nvarchar或varchar如果你传的是数字列得先CAST或CONVERT否则可能报类型错误。这一点跟 MySQL 的宽松处理不一样SQL Server 在这块比较严格。还有一个容易被忽略的点STRING_AGG会忽略NULL值。也就是说如果组内某行的拼接列是NULL它不会在结果里留下一个空的分隔符位置而是直接跳过。这个行为大多数时候是好事但如果你需要保留空位就得用ISNULL或COALESCE先把NULL转成空字符串。2.2 最小可复现的例子先建一张测试表模拟订单明细-- 建一张订单明细表一个订单对应多条商品 CREATE TABLE OrderDetail ( OrderNo VARCHAR(20), ProductName NVARCHAR(50), Qty INT ); INSERT INTO OrderDetail VALUES (A001, N苹果, 2), (A001, N香蕉, 3), (A001, N橙子, 1), (A002, N牛奶, 5), (A002, N面包, 2), (A003, NULL, 1); -- 故意留一个 NULL 测试然后用STRING_AGG把每个订单的商品拼起来-- 按订单号分组把商品名用逗号拼成一行 SELECT OrderNo, STRING_AGG(ProductName, N,) AS Products FROM OrderDetail GROUP BY OrderNo;跑出来的结果A001 是「苹果,香蕉,橙子」A002 是「牛奶,面包」A003 因为商品名是NULLSTRING_AGG直接返回NULL整组没有非空值可拼。这里就能看到NULL被跳过的行为如果 A003 有两行、一行是NULL一行是「可乐」那结果只会是「可乐」不会出现「,可乐」这种多余分隔符。参数说明第一个参数ProductName是NVARCHAR所以分隔符我也用了N,保持 Unicode 一致如果你拼的是VARCHAR列分隔符写,就行。分隔符本身不能是NULL传NULL会直接报错。2.3 排序让拼接顺序可控默认情况下STRING_AGG的拼接顺序是不保证的。虽然实践中经常看起来是按聚集索引或插入顺序但这是「玄学」不能依赖。要控制顺序得用WITHIN GROUP (ORDER BY ...)-- 按数量从大到小拼接顺序可控 SELECT OrderNo, STRING_AGG(ProductName, N,) WITHIN GROUP (ORDER BY Qty DESC) AS ProductsByQty FROM OrderDetail GROUP BY OrderNo;WITHIN GROUP是STRING_AGG的排序子句ORDER BY里可以写多列比如先按数量降序、再按商品名升序。这个子句在 SQL Server 2017 及以上才支持2016 及更早版本没有STRING_AGG自然也用不了。排序的代价是额外的 sort 操作数据量大时要注意执行计划里有没有出现昂贵的排序算子。2.4 去重STRING_AGG 没有 DISTINCT这是很多人踩的第一个坑STRING_AGG不支持DISTINCT。你写STRING_AGG(DISTINCT ProductName, ,)会直接语法报错。要去重得先在子查询里DISTINCT再聚合-- 先去重再聚合避免重复商品名 SELECT OrderNo, STRING_AGG(ProductName, N,) AS DistinctProducts FROM ( SELECT DISTINCT OrderNo, ProductName FROM OrderDetail WHERE ProductName IS NOT NULL ) t GROUP BY OrderNo;注意子查询里我加了WHERE ProductName IS NOT NULL因为DISTINCT会把NULL也当成一个独立值如果不去掉聚合时虽然STRING_AGG会跳过NULL但子查询里多一行NULL没意义还影响执行计划。这个写法在数据量大时DISTINCT的开销不小如果只是少量重复可以考虑用ROW_NUMBER()去重性能上有时更可控。3. 老版本怎么办FOR XML PATH 和 STUFF 的组合拳3.1 为什么老项目还在用这套写法SQL Server 2008 R2、2012、2014、2016 都没有STRING_AGG而这些版本在很多企业里还在跑。你不可能因为一个字符串拼接就去升级数据库所以FOR XML PATH这套写法必须掌握。它的思路是用FOR XML PATH把每行数据转成 XML 片段再用STUFF把开头的分隔符去掉最后得到一个拼接字符串。这套写法能流行十几年是因为它兼容性极好从 SQL Server 2005 就能用而且性能在多数场景下可以接受。缺点是代码长、可读性差遇到特殊字符比如、还会被 XML 转义需要额外处理。3.2 完整可抄的 FOR XML PATH 模板还是用上面的OrderDetail表把每个订单的商品拼起来-- 老版本通用写法FOR XML PATH STUFF SELECT OrderNo, STUFF(( SELECT N, ProductName FROM OrderDetail AS inner_t WHERE inner_t.OrderNo outer_t.OrderNo AND ProductName IS NOT NULL ORDER BY Qty DESC FOR XML PATH(), TYPE ).value(., NVARCHAR(MAX)), 1, 1, N) AS Products FROM (SELECT DISTINCT OrderNo FROM OrderDetail) AS outer_t;这段代码拆开看内层子查询对每个订单把, ProductName拼成一行行字符串FOR XML PATH()把它们连成一个 XML 文本TYPE关键字让它返回 XML 类型而不是字符串避免特殊字符被转义。然后.value(., NVARCHAR(MAX))把 XML 转回字符串此时开头会多一个逗号。最后STUFF(..., 1, 1, N)从第 1 位开始删掉 1 个字符也就是那个多余的逗号。参数说明FOR XML PATH()里的空字符串表示不生成行标签只拼内容TYPE一定要加否则、会被转义成amp;、lt;STUFF的四个参数分别是原字符串、起始位置、删除长度、替换字符串这里替换成空串就是删除。ORDER BY Qty DESC放在子查询里控制拼接顺序老版本没有WITHIN GROUP只能靠子查询排序。3.3 两种写法的性能对比与选择STRING_AGG是原生聚合执行计划里通常是一个流聚合或哈希聚合效率高代码短。FOR XML PATH本质上是相关子查询加 XML 序列化每个分组都要跑一次子查询数据量大时容易变成嵌套循环性能下降明显。我做过一个粗略测试10 万行、1 万个分组STRING_AGG大约 0.3 秒FOR XML PATH要 1.5 秒以上差距在 5 倍左右。但FOR XML PATH也不是一无是处。它支持在拼接时做更复杂的表达式比如拼接多个列、加条件判断灵活性反而更高。而且它不要求数据库版本迁移成本低。我的建议是新项目、SQL Server 2017 及以上一律用STRING_AGG老项目如果只是偶尔用FOR XML PATH够用如果老项目里字符串聚合是高频操作值得评估升级数据库或者用 CLR 聚合函数替代。提示FOR XML PATH写法里如果拼接的字符串本身包含 XML 特殊字符TYPE加.value()能正确还原但如果你漏了TYPE结果里会出现amp;这类转义排查时容易懵。4. 避坑与排查字符串聚合最常见的 5 个翻车现场4.1 拼接结果被截断只显示前 8000 个字符现象用STRING_AGG拼一个很长的字符串结果只出来 8000 字符左右后面没了。原因STRING_AGG的返回类型默认是NVARCHAR(4000)或VARCHAR(8000)超过就截断。解决在拼接前把表达式CAST成NVARCHAR(MAX)比如STRING_AGG(CAST(ProductName AS NVARCHAR(MAX)), N,)。注意STRING_AGG本身不接受MAX类型的直接返回但输入表达式转成MAX后结果也会是MAX不会截断。4.2 分隔符位置出现多余逗号或开头结尾有逗号现象拼出来的字符串开头或结尾多一个逗号或者中间出现连续两个逗号。原因开头结尾的逗号通常是FOR XML PATH写法忘了STUFF或者STUFF的起始位置写错中间连续逗号多半是拼接列里有空字符串STRING_AGG不会跳过空字符串只跳过NULL。解决老写法检查STUFF参数新写法用NULLIF(ProductName, )把空字符串转成NULL让STRING_AGG跳过。4.3 排序不生效拼接顺序每次都不一样现象明明写了ORDER BY但拼接结果的顺序还是乱的。原因ORDER BY写在了外层查询而不是STRING_AGG的WITHIN GROUP里。外层ORDER BY只影响结果集的行顺序不影响聚合内部的拼接顺序。解决把排序放进WITHIN GROUP (ORDER BY ...)老版本放进FOR XML PATH的子查询里。另外如果排序表达式有重复值拼接顺序仍然可能不稳定需要加一个唯一列做次级排序。4.4 特殊字符导致 XML 解析报错或结果异常现象用FOR XML PATH拼接包含、、的字符串结果里出现amp;、lt;或者直接报 XML 解析错误。原因FOR XML PATH默认会对 XML 特殊字符转义如果没加TYPE和.value()转义字符就留在结果里了。解决加上TYPE和.value(., NVARCHAR(MAX))让 SQL Server 正确处理转义。如果拼接内容里本身有非法 XML 字符比如某些控制字符还需要用REPLACE提前清理。4.5 大数据量下内存暴涨或查询超时现象对几百万行数据做字符串聚合查询跑很久甚至把tempdb撑满。原因字符串聚合本质上是把多行数据在内存里拼成一个长字符串数据量越大内存和tempdb压力越大。STRING_AGG和FOR XML PATH都躲不开这个限制。解决先过滤再聚合减少参与拼接的行数如果只是报表展示考虑在应用层拼接或者用分页分批处理实在要数据库做检查执行计划确保没有不必要的排序和哈希操作必要时加索引。5. 进阶技巧用窗口函数和 CTE 把字符串聚合玩出花5.1 用窗口函数做「累计拼接」STRING_AGG不仅能配合GROUP BY还能当窗口函数用实现「按时间累计拼接」。比如你想看每个订单的商品随着时间推移是怎么累加的-- 窗口函数版按订单分组按数量累计拼接 SELECT OrderNo, ProductName, STRING_AGG(ProductName, N,) WITHIN GROUP (ORDER BY Qty DESC) OVER (PARTITION BY OrderNo) AS AllProducts FROM OrderDetail WHERE ProductName IS NOT NULL;这里OVER (PARTITION BY OrderNo)让STRING_AGG在每个订单内聚合但结果会重复出现在每一行上。这个用法适合做「组内每一行都显示完整拼接结果」的报表省得再JOIN一次。注意窗口函数版的STRING_AGG不能和GROUP BY同时用否则报错。5.2 用 CTE 拆分再聚合处理复杂去重有时候去重逻辑不是简单的DISTINCT而是「每个商品只保留最新一条」。这时候可以先用 CTE 加ROW_NUMBER()标记再聚合-- 每个订单每个商品只保留数量最大的一条再拼接 WITH Ranked AS ( SELECT OrderNo, ProductName, Qty, ROW_NUMBER() OVER (PARTITION BY OrderNo, ProductName ORDER BY Qty DESC) AS rn FROM OrderDetail WHERE ProductName IS NOT NULL ) SELECT OrderNo, STRING_AGG(ProductName, N,) WITHIN GROUP (ORDER BY Qty DESC) AS Products FROM Ranked WHERE rn 1 GROUP BY OrderNo;这个模式在「标签去重」「最新状态汇总」这类需求里很常见。ROW_NUMBER()按订单和商品分组数量大的排前面rn 1就是每个商品只留一条。然后再用STRING_AGG拼接顺序用Qty DESC控制。相比直接DISTINCT这种写法能保留更多控制权比如按时间取最新、按优先级取最高。5.3 验证拼接结果是否正确的一个小习惯字符串聚合的结果是一长串肉眼很难核对。我一般会加一个「计数校验」同时输出COUNT(*)和拼接后的分隔符个数加一两者应该相等前提是没有NULL和空字符串。比如-- 校验拼接元素个数是否等于行数 SELECT OrderNo, STRING_AGG(ProductName, N,) AS Products, COUNT(*) AS Cnt, LEN(STRING_AGG(ProductName, N,)) - LEN(REPLACE(STRING_AGG(ProductName, N,), N,, N)) 1 AS SepCnt FROM OrderDetail WHERE ProductName IS NOT NULL GROUP BY OrderNo;SepCnt算的是分隔符个数加一正常情况下应该等于Cnt。如果不等说明拼接列里有空字符串或者分隔符本身出现在数据里需要进一步排查。这个习惯帮我省过很多次「看起来对、其实漏了」的后悔药。5.4 迁移到 STRING_AGG 时的一个实用检查清单从FOR XML PATH迁移到STRING_AGG我一般按这个顺序检查第一确认数据库版本是 2017 及以上SELECT VERSION看一眼第二把FOR XML PATH子查询里的ORDER BY搬到WITHIN GROUP第三检查有没有DISTINCT有的话改成子查询去重第四检查拼接列有没有NULL和空字符串NULL不用管空字符串用NULLIF处理第五把STUFF那层去掉直接STRING_AGG第六跑一遍对比新旧结果用上面的计数校验确认元素个数一致。这套流程走下来基本不会出岔子。希望帮到你。本文还有配套的精品资源点击获取