简介：这份资源聚焦 SQL Server 中字符串聚合这一常见却容易被忽视的查询需求，面向有一定 T-SQL 基础、需要处理分组字符串拼接的数据库开发与运维人员。当 SUM、AVG、COUNT、MAX、MIN 等数值聚合函数无法满足需求时，资源给出了通过自定义函数实现字符串合并的完整思路，并以 AggregationTable 测试表为例，演示将同一 Id 下的多个 Name 拼接为“赵孙李”“钱周”的聚合结果，同时提及 SQL Server 2017 及以上版本可用的 STRING_AGG 内置函数作为替代方案。资源包为 1 个 PDF 文件，大小约 35KB，内容紧凑，便于快速查阅与收藏。目前已有 3509 人学习下载，适合希望掌握字符串聚合写法、理解自定义函数与内置函数差异的读者参考借鉴。
1. 字符串聚合：当 SUM 和 COUNT 都使不上劲时该怎么办
手上有一张AggregationTable，两列：Id和Name。数据长这样——Id 为 1 的有赵、孙、李三条，Id 为 2 的有钱、周两条。现在业务方要一张报表，每个 Id 只出一行，Name 拼成一串：1 对应"赵孙李"，2 对应"钱周"。你第一反应可能是GROUP BY Id加个聚合函数，但把 SUM、AVG、COUNT、MAX、MIN 在脑子里过一遍就会发现全都不对路——这些函数要么算数值总和，要么数行数，要么比大小，没有一个能把多行文本首尾相接。这不是写法问题，是标准聚合函数的语义边界。SQL Server 在 2017 之前没有内置的字符串聚合，所以这类需求在老版本里只能靠自定义函数兜底。这篇笔记就围绕这个自定义函数展开，把建表、写函数、调用、踩坑、以及新版本 STRING_AGG 的替代方案一次讲透，适合还在维护 SQL Server 2008/2012/2014/2016 的 DBA 和后端开发照着复现。
2. 自定义聚合函数：从建表到出结果的完整链路
2.1 为什么标量函数能"绕过"聚合的限制
标准聚合函数之所以做不到字符串拼接，是因为它们的返回类型被限定在数值或单值比较上。SUM 返回数值累加，COUNT 返回整数，MAX/MIN 返回同类型单值。而字符串拼接的本质是"逐行累加到一个变量上"，这在 T-SQL 里恰好可以用标量函数配合SELECT @变量 = @变量 + 列的写法实现。这个写法的关键在于：SQL Server 允许在 SELECT 赋值语句中，对结果集的每一行依次执行赋值操作，于是变量就像滚雪球一样把每行的 Name 追加进去。理解这一点，后面看函数体就不会觉得是黑魔法了。
需要提前说清楚一个边界：这种"逐行累加"依赖执行计划按顺序扫描行，官方并没有把它列为保证行为。实践中绝大多数情况结果顺序和聚集索引或表扫描顺序一致，但如果你对拼接顺序有严格要求，得在函数内部或外部显式控制排序，这一点后面避坑章节会展开。
2.2 建测试表和插入数据
先把环境搭起来。下面这段脚本建一张两列的表，然后插入五行样例数据，和正文里的数据完全一致。
-- 建测试表：Id 为分组列，Name 为待聚合的字符串列 create table AggregationTable( Id int, [Name] varchar(10) ) go -- 插入五行测试数据，注意用 union all 而不是 union insert into AggregationTable select 1,'赵' union all select 2,'钱' union all select 1,'孙' union all select 1,'李' union all select 2,'周' go逻辑说明：[Name]加了方括号是因为 Name 在某些上下文里可能被当作关键字，加括号是稳妥习惯。插入时用union all而不是union，因为union会去重，万一有两条完全相同的记录会被吞掉一行，聚合结果就少了一个字。参数方面，varchar(10)对单个汉字够用，但如果你的实际字段可能更长，建表时就要放大长度，否则插入阶段就截断了。
2.3 创建 AggregateString 标量函数
核心就是这个函数。它接收一个@Id，在函数体里声明一个字符串变量，通过 SELECT 赋值把匹配行的 Name 依次拼上去，最后返回。
-- 创建自定义字符串聚合函数 Create FUNCTION AggregateString ( @Id int ) RETURNS varchar(1024) AS BEGIN declare @Str varchar(1024) set @Str = '' -- 逐行把 Name 追加到 @Str 上 select @Str = @Str + [Name] from AggregationTable where [Id] = @Id return @Str END GO逻辑说明：函数返回类型定为varchar(1024)，这是拼接结果的上限。如果某个 Id 下的 Name 拼起来超过 1024 个字符，结果会被截断且不报错，这是最隐蔽的坑之一。set @Str = ''这步不能省，否则变量初值为 NULL，NULL + 任何字符串还是 NULL，整个结果就空了。where [Id] = @Id是过滤条件，保证只拼当前分组的数据。
参数说明：@Id int要和表里 Id 的类型一致，如果表里是 bigint 而函数参数写 int，遇到超过 int 范围的值会报算术溢出。返回类型的长度要按业务实际最大拼接长度来定，宁可放大到varchar(8000)也别卡在 1024。
2.4 调用函数并验证结果
函数建好后，用GROUP BY Id配合函数调用就能出结果。
-- 按 Id 分组，对每组调用自定义函数拼接 Name select dbo.AggregateString(Id) as Name, Id from AggregationTable group by Id逻辑说明：这里group by Id的作用是把 Id 去重成两组，然后对每个 Id 值调用一次AggregateString。注意函数调用必须带dbo.前缀，否则在非默认架构下会报"找不到函数"。执行后应得到 Id=1 对应"赵孙李"，Id=2 对应"钱周"。如果结果顺序和你预期不同，那是扫描顺序的问题，不是函数写错了。
参数说明：group by Id里的 Id 和函数参数是同一个列，这是这种写法的固定套路。如果你的分组列不止一个，比如按 Id 和 Type 两列分组，函数就得改成接收两个参数，或者把过滤条件改成拼接后的复合键。
3. 避坑与排查：自定义字符串聚合的五个血泪经验
3.1 拼接结果为 NULL 或空串
现象：调用函数后返回 NULL，或者明明有数据却返回空字符串。原因通常是set @Str = ''这行被漏掉，变量初值为 NULL，NULL + '赵'结果还是 NULL。另一种情况是where条件写错，比如把[Id] = @Id写成了[Id] = 1，导致所有分组都返回同一组数据。解决办法：先单独跑一遍select * from AggregationTable where Id = 1确认有数据，再检查函数体里变量初始化那行在不在。
3.2 拼接顺序不稳定
现象：同样的数据，今天查出来是"赵孙李"，明天变成"李孙赵"。原因：select @Str = @Str + [Name]的赋值顺序依赖执行计划，当表数据量变化、索引调整或并行度改变时，扫描顺序可能变。解决办法：如果业务对顺序有要求，在函数内的 SELECT 上加order by并不能可靠生效（标量函数里的 order by 常被优化器忽略），更稳的做法是把排序键也纳入拼接逻辑，或者干脆升级到 STRING_AGG 用WITHIN GROUP (ORDER BY ...)显式排序。
3.3 结果被静默截断
现象：某个 Id 下明明有十几条记录，拼出来却只有前几条。原因：返回类型varchar(1024)装不下，超出部分被无声截断，不报任何错。解决办法：先跑一句select Id, sum(len(Name)) from AggregationTable group by Id算出每个分组的理论最大长度，把返回类型放大到足够。如果超过 8000，就得改用varchar(max)，但要注意标量函数返回 max 类型在某些场景下性能会下降。
3.4 大数据量下性能断崖
现象：小表跑得飞快，数据量上到几十万行后查询几分钟不出结果。原因：标量函数是逐行调用的，group by有多少个分组就调用多少次函数，每次函数内部又扫一遍表，复杂度接近分组数乘以表行数。解决办法：给Id列建索引，让函数内部的where [Id] = @Id走索引查找而不是全表扫描。如果分组数很多，考虑用FOR XML PATH或升级到 STRING_AGG 这类集合级方案替代逐行调用。
3.5 函数名冲突与架构问题
现象：调用时报"找不到对象 AggregateString"或"不是可识别的函数名"。原因：函数建在了非 dbo 架构下，或者当前数据库上下文不对。解决办法：建函数时显式写create function dbo.AggregateString，调用时也带dbo.前缀。跨数据库调用要写全库名.dbo.AggregateString。另外注意，标量函数不能跨数据库引用表，函数体里的AggregationTable必须是函数所在库的表。
4. 进阶：STRING_AGG 替代方案与版本选型
如果你用的是 SQL Server 2017 及以上版本，内置的STRING_AGG能直接干掉上面这一整套自定义逻辑，而且支持显式排序和分隔符。写法如下：
-- SQL Server 2017+ 内置字符串聚合，支持分隔符和排序 select Id, string_agg([Name], '') within group (order by [Name]) as Name from AggregationTable group by Id逻辑说明：string_agg([Name], '')第一个参数是待聚合列，第二个参数是分隔符，这里传空串表示直接首尾相接。within group (order by [Name])显式指定拼接顺序，解决了自定义函数顺序不稳定的问题。结果和自定义函数一致，但执行计划是集合级的，大数据量下性能差距明显。
版本选型上给个对照：
| 版本 | 字符串聚合方案 | 排序可控 | 性能 |
|---|---|---|---|
| 2008/2008R2 | 自定义标量函数 | 不可靠 | 差 |
| 2012/2014/2016 | 自定义函数或 FOR XML PATH | FOR XML 可控 | 中 |
| 2017 及以上 | STRING_AGG | 完全可控 | 好 |
FOR XML PATH是 2017 之前的另一个常用方案，写法是把行转成 XML 再拼，能配合子查询控制顺序，但语法绕、特殊字符要转义，维护成本高。我一般会先确认目标库版本，2017 以上直接上 STRING_AGG，2016 及以下才考虑自定义函数或 FOR XML。
还有一个容易忽略的点：STRING_AGG 的结果类型默认是nvarchar(max)，如果业务需要varchar，得显式cast一下，否则可能触发隐式转换影响索引使用。分隔符如果传 NULL，整个聚合结果会变成 NULL，这点和自定义函数里变量初值为 NULL 的坑如出一辙。
从那以后我每次写字符串聚合，都会先跑一句select @@version确认版本，再决定用 STRING_AGG 还是自定义函数，并且强制检查返回类型长度够不够。希望帮到你。
本文还有配套的精品资源，点击获取
