简介这份资源聚焦 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 这步不能省否则变量初值为 NULLNULL 任何字符串还是 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.前缀否则在非默认架构下会报找不到函数。执行后应得到 Id1 对应赵孙李Id2 对应钱周。如果结果顺序和你预期不同那是扫描顺序的问题不是函数写错了。参数说明group by Id里的 Id 和函数参数是同一个列这是这种写法的固定套路。如果你的分组列不止一个比如按 Id 和 Type 两列分组函数就得改成接收两个参数或者把过滤条件改成拼接后的复合键。3. 避坑与排查自定义字符串聚合的五个血泪经验3.1 拼接结果为 NULL 或空串现象调用函数后返回 NULL或者明明有数据却返回空字符串。原因通常是set Str 这行被漏掉变量初值为 NULLNULL 赵结果还是 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 PATHFOR XML 可控中2017 及以上STRING_AGG完全可控好FOR XML PATH是 2017 之前的另一个常用方案写法是把行转成 XML 再拼能配合子查询控制顺序但语法绕、特殊字符要转义维护成本高。我一般会先确认目标库版本2017 以上直接上 STRING_AGG2016 及以下才考虑自定义函数或 FOR XML。还有一个容易忽略的点STRING_AGG 的结果类型默认是nvarchar(max)如果业务需要varchar得显式cast一下否则可能触发隐式转换影响索引使用。分隔符如果传 NULL整个聚合结果会变成 NULL这点和自定义函数里变量初值为 NULL 的坑如出一辙。从那以后我每次写字符串聚合都会先跑一句select version确认版本再决定用 STRING_AGG 还是自定义函数并且强制检查返回类型长度够不够。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/9/26 9:15:36 · 阅读 1.2k SQL Server字符串聚合：自定义函数与STRING_AGG方案详解
简介这份资源聚焦 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 这步不能省否则变量初值为 NULLNULL 任何字符串还是 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.前缀否则在非默认架构下会报找不到函数。执行后应得到 Id1 对应赵孙李Id2 对应钱周。如果结果顺序和你预期不同那是扫描顺序的问题不是函数写错了。参数说明group by Id里的 Id 和函数参数是同一个列这是这种写法的固定套路。如果你的分组列不止一个比如按 Id 和 Type 两列分组函数就得改成接收两个参数或者把过滤条件改成拼接后的复合键。3. 避坑与排查自定义字符串聚合的五个血泪经验3.1 拼接结果为 NULL 或空串现象调用函数后返回 NULL或者明明有数据却返回空字符串。原因通常是set Str 这行被漏掉变量初值为 NULLNULL 赵结果还是 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 PATHFOR XML 可控中2017 及以上STRING_AGG完全可控好FOR XML PATH是 2017 之前的另一个常用方案写法是把行转成 XML 再拼能配合子查询控制顺序但语法绕、特殊字符要转义维护成本高。我一般会先确认目标库版本2017 以上直接上 STRING_AGG2016 及以下才考虑自定义函数或 FOR XML。还有一个容易忽略的点STRING_AGG 的结果类型默认是nvarchar(max)如果业务需要varchar得显式cast一下否则可能触发隐式转换影响索引使用。分隔符如果传 NULL整个聚合结果会变成 NULL这点和自定义函数里变量初值为 NULL 的坑如出一辙。从那以后我每次写字符串聚合都会先跑一句select version确认版本再决定用 STRING_AGG 还是自定义函数并且强制检查返回类型长度够不够。希望帮到你。本文还有配套的精品资源点击获取