SQL多行合并到一列：四大数据库聚合语法与踩坑指南

1. 多行合并到一列，本质上是在解决哪类问题

先说说我为什么想写这个主题。前两天在群里帮一个朋友看需求，他要做订单导出，一张订单对应多个商品明细，需要把商品名称、数量、规格拼成一个备注字段输出到Excel里。这不就是典型的“SQL多行数据合并到一行中的一个字段”吗？看起来很简单，但真写起来，不同数据库语法不一样，排序、去重、分隔符处理各有讲究，稍微不注意就会踩到截断、乱码、性能的坑。这篇文章我把这个场景从头到尾拆一遍，把我踩过的坑和验证过的方法都写出来。

这类需求在工作里出现频率比我预期的高得多，常见的有三类：

第一类：明细汇总进父表字段。一个订单有多个明细行，把明细的商品名拼成一个字符串放到订单表里；一个部门有多个员工，把员工姓名拼成一个字段放到部门视图里。这类需求本质上是“一对多”关系中的多端要“坍缩”成一行的某个字段。

第二类：标签和枚举扁平化。用户有多个兴趣标签，需要从子表拼成“篮球、跑步、阅读”这种逗号分隔串，用于展示或数据导出。这类场景常常还要带上排序规则和去重规则，比如标签按类型排序、相同标签只保留一次。

第三类：报表透视。做数据透视或宽表时，需要把某一列的多个值合并到单元格里。这时候往往不只是简单拼接，还要考虑空值、重复值、特定分隔符，甚至输出成JSON结构供下游消费。

先明确一下输入输出形态。假设有张订单明细表：

目标是把同订单号的多行合并成一行，比如输出：

为什么不能直接用普通聚合函数？SUM、COUNT处理的是数值和计数，对字符串拼接无能为力；GROUP BY分组后每组的行仍然是一行行存在，并不会“自动变成一列”。很多人第一次遇到这个问题时，最先想到的是在应用层做循环拼接，但这意味着要先把明细数据全部捞出来，然后在Java/Python里逐条拼，数据量大了以后无论是网络传输还是内存开销都不划算。SQL层面直接解决，是最快也最稳妥的方案。

而且注意，这类需求大部分时候并不是单纯拼接，而是要带着业务规则：排序规则（比如按时间、按数字大小）、去重逻辑（重复标签不能出现两次）、分隔符策略（逗号、竖线还是JSON）以及长度边界（拼到多长会被截断）。这些细节才是真正体现功力的地方，后面逐个拆。

2. 四大主流数据库的合并语法：别用错地方

不同数据库提供了不同的字符串聚合函数，先逐个说清楚，后面再讲细节坑。

2.1 MySQL：GROUP_CONCAT是主力

MySQL里最常用的就是GROUP_CONCAT。基本语法：

SELECT 订单号, GROUP_CONCAT(CONCAT(商品名称, 'x', 数量) SEPARATOR ', ') AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

这个函数的完整语法是：

GROUP_CONCAT( [DISTINCT] expr [, expr ...] [ORDER BY {unsigned_integer | col_name | expr} [ASC | DESC]] [SEPARATOR str_val] )

几个关键点：

• SEPARATOR指定分隔符，默认是逗号，但默认不带空格，也就是“苹果,香蕉”这样。
• DISTINCT可以对合并值去重。
• ORDER BY可以控制合并顺序，且排序和分组字段可以不同。
• 生成的类型是TEXT。

需要注意MySQL的排序是在聚合函数内部完成的，比如按数量排序再拼接：

SELECT 订单号, GROUP_CONCAT(商品名称 ORDER BY 数量 DESC SEPARATOR '、') AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

不过这里有个常见误区：ORDER BY 数量如果多个商品数量相同，顺序是不确定的，想要完全稳定还得再拼一个次级排序字段。

2.2 SQL Server：从FOR XML PATH到STRING_AGG

SQL Server 2017之前没有专用的聚合拼接函数，最经典的做法是FOR XML PATH加STUFF：

SELECT a.订单号, STUFF(( SELECT ', ' + 商品名称 FROM 订单明细表 b WHERE b.订单号 = a.订单号 ORDER BY b.数量 DESC FOR XML PATH('') ), 1, 2, '') AS 商品汇总 FROM (SELECT DISTINCT 订单号 FROM 订单明细表) a;

这里FOR XML PATH('')的作用是把子查询的多行结果拼成一个XML字符串，由于传入空路径，只会输出纯文本。为什么外面要套STUFF？因为内层拼接出来的结果是“, 苹果, 香蕉”，前面多了一个分隔符，STUFF(字符串, 1, 2, '')的意思是从第1个字符开始删除2个字符，再用空字符串替换，也就是把开头的“, ”去掉。这一段逻辑是SQL Server老玩家都会背的写法，但理解清楚比背下来更重要。

SQL Server 2017及以后版本有了专用函数STRING_AGG，写法大幅简化：

SELECT 订单号, STRING_AGG(商品名称, ', ') WITHIN GROUP (ORDER BY 数量 DESC) AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

注意WITHIN GROUP是STRING_AGG特有的排序语法，排序只影响拼接顺序，不会改变分组逻辑。

2.3 Oracle：LISTAGG是标准答案

Oracle的LISTAGG是最直观的聚合拼接函数：

SELECT 订单号, LISTAGG(商品名称, ', ') WITHIN GROUP (ORDER BY 数量 DESC) AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

Oracle 11.2之后的版本都有LISTAGG。老版本里有人用WM_CONCAT，这个函数是Oracle内部函数，既不正式也早已废弃，排序支持还特别差，不建议在生产环境里碰它。

LISTAGG有个比较隐蔽的限制：返回值是VARCHAR2类型，总长度不能超过4000字节（也有版本限制是4000字符），超过会直接报错ORA-01489: result of string concatenation is too long。这个问题后面专门讲。

2.4 PostgreSQL：STRING_AGG和ARRAY_AGG

PostgreSQL从9.0开始有STRING_AGG：

SELECT 订单号, STRING_AGG(商品名称, ', ' ORDER BY 数量 DESC) AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

注意PostgreSQL的STRING_AGG排序语法直接把ORDER BY写在聚合参数里，不写WITHIN GROUP。

如果场景需要保留每个元素的结构化信息，ARRAY_AGG可以把多行聚合成数组，再配合array_to_string转成字符串：

SELECT 订单号, array_to_string(ARRAY_AGG(商品名称 ORDER BY 数量 DESC), ', ') AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

这种方式做去重也方便，ARRAY_AGG(DISTINCT 商品名称)直接用。

画个表格快速对照：

这张表值得收藏，因为很多人换数据库时容易把语法记混，直接对照看能省不少时间。

3. 合并字段的排序、去重和分隔符：细节决定结果对不对

语法背熟只是第一步，真实业务里的复杂度都在细节里。

3.1 排序：聚合顺序不等于业务顺序

先说MySQL。GROUP_CONCAT内部支持ORDER BY，这个顺序是聚合内部遍历行的顺序，但有一个要注意的地方：只有当排序字段是索引覆盖或能够稳定反映业务顺序时才可靠。比如按明细ID升序排列往往能复现“录入顺序”，但如果按一个经常变化的字段比如“更新时间”排序，同一批数据不同时间查询结果可能会不一样。

示例：按数量降序、再按商品名升序拼接：

SELECT 订单号, GROUP_CONCAT(商品名称 ORDER BY 数量 DESC, 商品名称 ASC SEPARATOR '、') AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

SQL Server的STRING_AGG用WITHIN GROUP，排序标准最明确：

SELECT 订单号, STRING_AGG(商品名称, '、') WITHIN GROUP (ORDER BY 数量 DESC, 商品名称 ASC) AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

Oracle的LISTAGG也是WITHIN GROUP，写法几乎一样。这里有个经验：排序字段尽量不要用拼接表达式本身，比如不要对CONCAT(商品名称, 数量)做排序，很容易产生非预期结果；要用原始列排序。

如果在旧版SQL Server用FOR XML PATH，排序写在子查询内部，ORDER BY位置在FOR XML PATH之前：

SELECT a.订单号, STUFF(( SELECT '、' + 商品名称 FROM 订单明细表 b WHERE b.订单号 = a.订单号 ORDER BY b.数量 DESC, b.商品名称 ASC FOR XML PATH('') ), 1, 1, '') AS 商品汇总 FROM (SELECT DISTINCT 订单号 FROM 订单明细表) a;

注意这里的STUFF第一个参数我写的是'、'长度为1，所以删除1个字符。

3.2 去重：函数支持不了就上子查询

MySQL的GROUP_CONCAT(DISTINCT 字段)和PostgreSQL的STRING_AGG(DISTINCT 字段, ', ')可以直接去重。但SQL Server和Oracle不支持在聚合函数内部直接去重字符串，通常的做法是先在子查询或CTE里SELECT DISTINCT，再在外部做拼接聚合。

举个例子，Oracle里要去重拼接标签：

WITH tag_list AS ( SELECT DISTINCT 用户ID, 标签 FROM 用户标签表 ) SELECT 用户ID, LISTAGG(标签, '、') WITHIN GROUP (ORDER BY 标签) AS 标签汇总 FROM tag_list GROUP BY 用户ID;

用CTE先做去重，把干扰项清掉，再聚合，逻辑清楚，也不容易出错。SQL Server可以把DISTINCT直接加到子查询的SELECT里，原理一样。

另外要注意，如果去重时想保留“最新”或“最大”的那一条，单纯DISTINCT解决不了，要用窗口函数ROW_NUMBER()把目标行筛选出来再聚合：

WITH ranked AS ( SELECT 订单号, 商品名称, ROW_NUMBER() OVER (PARTITION BY 订单号, 商品名称 ORDER BY 数量 DESC) AS rn FROM 订单明细表 ) SELECT 订单号, GROUP_CONCAT(商品名称 ORDER BY 数量 DESC SEPARATOR '、') AS 商品汇总 FROM ranked WHERE rn = 1 GROUP BY 订单号;

这个方法跨数据库通用，是处理“每个分组内按某个规则保留一条”的万能模板。

3.3 分隔符：你以为选个逗号就完事了吗

分隔符看起来是小事，实际上容易踩坑。

• 如果拼接结果要被Excel打开，逗号分隔虽然自然，但内容里本身包含逗号（比如商品名带英文逗号）时会导致列错位。更稳妥的是用竖线|或者分号;。
• 如果内容要作为列表标签用于前端展示，常见选择是中文顿号、，但这个字符要不要保留空格完全看需求，两边得对齐。
• 如果下游要解析，最好直接输出JSON。MySQL 8、PostgreSQL、SQL Server都有JSON聚合能力，后面第5章细说。
• 如果拼接字段很长，分隔符本身也占字节，尤其在中文字符集下，分隔符长度会影响总长度上限，Oracle场景要特别留意。

还有一个小坑：MySQL的GROUP_CONCAT如果指定SEPARATOR ''，可以做到无缝拼接，比如把所有账号名拼成一个连续字符串。但这时候某些数据库的默认行为会吃掉NULL值，导致拼接结果里出现连续分隔符，比如“苹果,,香蕉”。这个问题在第3.4节详细讲。

3.4 NULL值处理：奇怪结果的常见源头

很多人在多行合并时遇到“结果里有一堆连续分隔符”的怪象，原因都是某一行的拼接字段是NULL。

MySQL的GROUP_CONCAT和PostgreSQL的STRING_AGG会忽略NULL值，也就是说如果有一个商品的名称是NULL，合并结果里不会出现“苹果,,香蕉”，而是直接“苹果,香蕉”。这个行为有时候是好事，有时候反而是坏事——如果你需要明确标记“空值”，得先把NULL转成占位符：

SELECT 订单号, GROUP_CONCAT(IFNULL(商品名称, '未知商品') SEPARATOR '、') AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

Oracle的LISTAGG同样会忽略NULL，但SQL Server的STRING_AGG在2017版本里遇到NULL也会自动跳过。旧版FOR XML PATH同样跳过NULL。如果业务上有“空值也必须占位”的需求，统一用ISNULL或COALESCE处理后再聚合，不要依赖数据库默认行为。

另外有个容易被忽略的点：如果一组数据里所有行的目标字段都是NULL，聚合结果会变成NULL，而不是空字符串。这会导致下游处理时空值判断逻辑写错，建议在聚合外层再套一个COALESCE：

SELECT 订单号, COALESCE(GROUP_CONCAT(商品名称 SEPARATOR '、'), '') AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

3.5 一个完整的例子：标签统计带排序去重

综合上面几个细节，写一个实战一点的例子。需求是：每个用户聚合他的标签，标签去重、按标签类型分组排序、用顿号分隔、空标签不显示。

MySQL：

SELECT 用户ID, GROUP_CONCAT( DISTINCT CONCAT(标签类型, ':', 标签名称) ORDER BY 标签类型 ASC, 标签名称 ASC SEPARATOR '、' ) AS 标签汇总 FROM 用户标签表 WHERE 标签名称 IS NOT NULL AND 标签名称 <> '' GROUP BY 用户ID;

Oracle：

WITH cleaned AS ( SELECT DISTINCT 用户ID, 标签类型, 标签名称 FROM 用户标签表 WHERE 标签名称 IS NOT NULL AND 标签名称 <> '' ) SELECT 用户ID, LISTAGG(标签类型 || ':' || 标签名称, '、') WITHIN GROUP (ORDER BY 标签类型 ASC, 标签名称 ASC) AS 标签汇总 FROM cleaned GROUP BY 用户ID;

这样的写法放到真实报表里基本不用改。

4. 长度截断、字符转义和性能：最容易翻车的三个深坑

函数能用不代表能安全用。这一章我主要讲实测中翻过车的地方。

4.1 MySQL：group_concat_max_len是隐形杀手

MySQL的GROUP_CONCAT返回结果是TEXT，但会受到group_concat_max_len参数限制，默认值是1024。也就是说，合并出来的字符串超过1024字节就会被静默截断，不会报错，也不会给任何警告。业务的排查难度很高，因为你看到的只是“少了一段”，但不知道是哪一段丢的、为什么丢。

解决办法有两种。第一种是会话级调整参数：

SET SESSION group_concat_max_len = 102400;

第二种是全局调整，修改配置文件或在启动参数里指定：

group_concat_max_len=102400

我的建议是，如果业务里存在这类字段聚合需求，提前在配置文件里调大，而不是等出了问题再临时SET SESSION。生产环境一条SQL的执行计划不一定走你设过session的连接，踩过一次就知道痛了。

还有一点，group_concat_max_len的单位是字节还是字符？官方文档写的是字节，但不同版本、不同字符集下表现有差异。在UTF-8字符集下，一个中文占3个字节，1024的默认值实际上能存的中文字符很少。多语言场景务必留足余量。

4.2 SQL Server：FOR XML PATH的XML字符转义

旧版SQL Server用FOR XML PATH拼接时，有个特别坑的行为：结果中的<、>、&等字符会被XML转义成<、>、&。如果业务数据里包含这些字符（商品名、备注、日志文本里特别常见），拼接结果会直接出现乱码式的转义序列。

解决方法是把FOR XML PATH('')改成FOR XML PATH(''), TYPE，然后用.value('.', 'NVARCHAR(MAX)')取文本值，这样能避免转义。完整写法：

SELECT a.订单号, STUFF(( SELECT '、' + 商品名称 FROM 订单明细表 b WHERE b.订单号 = a.订单号 ORDER BY b.数量 DESC FOR XML PATH(''), TYPE ).value('.', 'NVARCHAR(MAX)'), 1, 1, '') AS 商品汇总 FROM (SELECT DISTINCT 订单号 FROM 订单明细表) a;

这个写法和不加TYPE的区别很多人搞不清楚，实际是：不加TYPE时结果是隐式转换的字符串，XML转义规则生效；加了TYPE后结果是XML类型，再用.value()取出来就是原始文本。这也是明明网上教程都这么写，你却总感觉拼接结果“多了点什么”的原因。

4.3 Oracle：LISTAGG的4000字符上限

Oracle的LISTAGG返回VARCHAR2，默认长度上限是4000字节，字符集为UTF-8时一个汉字占3字节，实际能拼进去的汉字只有1300多个。一旦超出，直接报错ORA-01489，SQL跑都跑不了。

常用替代方案是用XMLAGG：

SELECT 订单号, RTRIM( XMLAGG( XMLELEMENT(e, 商品名称 || '、') ORDER BY 数量 DESC ).EXTRACT('//text()') ) AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

XMLAGG返回的是CLOB类型，长度上限大得多，但写法比LISTAGG啰嗦，EXTRACT的写法在不同Oracle版本里兼容性也有差异。实测中这个方案能解决大部分超长拼接问题，但执行性能比LISTAGG差一些，如果数据量很大要注意。

还有一条思路是把拼接放到应用层：数据库只做基础分组，把明细行的关键字段按行返回，由后端代码循环拼接。这样做灵活性强，排序、去重、长度控制都方便，代价是传输数据量变大，适合明细行数不多的场景。

4.4 性能：索引、子查询和避免重复计算

多行合并SQL的性能问题通常出在两个地方：分组字段无索引，以及子查询关联查询使用不当。

分组聚合前，GROUP BY字段最好有索引。这里有一个容易被忽略的点：当你用FOR XML PATH这类关联子查询写法时，子查询的关联字段（比如订单号）一定要有索引，否则每条主记录都会触发一次全表扫描，慢到让人怀疑人生。CONNECT BY这种写法就不提了，很多老项目里的写法放在新数据量下根本跑不动。

MySQL的GROUP_CONCAT性能相对好，因为它在同一分组内一次遍历完成，但要注意不要在分组前先把两张表做一个巨大的笛卡尔积再聚合。正确姿势是先过滤、再关联、最后分组。举例说明一个反面写法：

-- 反例：先JOIN出大量中间行再聚合 SELECT o.订单号, GROUP_CONCAT(p.商品名称 SEPARATOR '、') FROM 订单表 o LEFT JOIN 订单明细表 d ON o.订单号 = d.订单号 LEFT JOIN 商品表 p ON d.商品ID = p.商品ID GROUP BY o.订单号;

这个写法在明细表记录数多时，会把中间结果撑得很大。更稳的写法是先聚合明细、再关联主表：

SELECT o.订单号, d.商品汇总 FROM 订单表 o LEFT JOIN ( SELECT 订单号, GROUP_CONCAT(商品名称 ORDER BY 数量 DESC SEPARATOR '、') AS 商品汇总 FROM 订单明细表 GROUP BY 订单号 ) d ON o.订单号 = d.订单号;

道理很简单：能让聚合先缩小的先缩小，减少进入JOIN的数据量。

还有个细节是避免在聚合表达式里重复计算同一条数据字段。比如要拼“商品名(数量)”这种格式，先在派生表或CTE里把CONCAT(商品名称, '(', 数量, ')')算好，再在外面做聚合拼接，避免GROUP_CONCAT内部做复杂表达式导致临时表开销增加。

5. 真实项目里的扩展玩法：JSON聚合、大数据平台与后端配合

字符串拼接只是入门，实际项目里会遇到更进阶的需求，挑几个有价值的展开。

5.1 聚合输出JSON：结构化表达比纯字符串更可靠

把多行合并成JSON数组是近年来越来越常见的需求。MySQL 5.7时代只能手工拼CONCAT('[', GROUP_CONCAT(JSON_OBJECT(...)), ']')，既冗长又容易出错。MySQL 8.0直接提供JSON_ARRAYAGG：

SELECT 订单号, JSON_ARRAYAGG(JSON_OBJECT('name', 商品名称, 'qty', 数量)) AS 商品列表 FROM 订单明细表 GROUP BY 订单号;

PostgreSQL的写法是：

SELECT 订单号, jsonb_agg(jsonb_build_object('name', 商品名称, 'qty', 数量) ORDER BY 数量 DESC) AS 商品列表 FROM 订单明细表 GROUP BY 订单号;

SQL Server从2016开始支持FOR JSON PATH：

SELECT 订单号, ( SELECT 商品名称 AS name, 数量 AS qty FROM 订单明细表 d WHERE d.订单号 = o.订单号 ORDER BY d.数量 DESC FOR JSON PATH ) AS 商品列表 FROM (SELECT DISTINCT 订单号 FROM 订单明细表) o;

为什么要输出JSON？因为纯字符串拼接一旦包含逗号、顿号、引号，下游解析时极容易出错；JSON有标准的转义规则，解析安全，还保留结构。如果这一步对接的是后端接口，前端拿到JSON数组可以直接渲染，不用split字符串再trim，体验完全不同。

5.2 大数据平台：Hive和Spark的拼接方式

离线数仓里这类需求同样高频。Hive里常见写法是CONCAT_WS配合COLLECT_LIST或COLLECT_SET：

SELECT 订单号, CONCAT_WS('、', COLLECT_LIST(商品名称)) AS 商品汇总 FROM 订单明细表 GROUP BY 订单号;

COLLECT_LIST保留所有值包括重复值，COLLECT_SET自动去重但丢失顺序（实际上Hive里集合顺序并不可控）。如果想控制顺序，需要先在子查询里用DISTRIBUTE BY和SORT BY做好全局排序，再在外层聚合。这个顺序问题经常让数仓同学头疼，建议直接在子查询里先排序：

SELECT 订单号, CONCAT_WS('、', COLLECT_LIST(商品名称)) AS 商品汇总 FROM ( SELECT 订单号, 商品名称 FROM 订单明细表 DISTRIBUTE BY 订单号 SORT BY 数量 DESC ) t GROUP BY 订单号;

Spark SQL里用collect_list或collect_set，配合CONCAT_WS，写法思路基本一致。区别是Spark支持sort_array等更灵活的集合操作，排序可以放在聚合之后处理。

5.3 与后端代码配合：字段映射和长度约定

说个亲身经历。之前做接口联调，后端Java用MyBatis映射一个聚合字段，数据库表定义的是VARCHAR(500)，但聚合结果实际长度经常到800多，结果插入时字段被截断，数据默默丢了一段。排查了很久才意识到是表结构长度不够。

这里有两个经验：第一，凡是会存储多行合并结果的字段，类型要么给TEXT/CLOB，要么给很长的VARCHAR，别按“大概长度”估，直接按最坏情况算；第二，后端解析分隔符字符串时，注意分隔符和内容里可能出现的特殊字符是否冲突，建议服务端和数据库约定统一的分隔策略，比如统一用竖线|，解析时用split("\\|")而不是split(",")。

如果项目里用MyBatis-Plus这类工具基于Java实体类自动生成建表SQL，聚合字段的映射类型也要提前设计好。实体类字段如果是String，生成到MySQL里默认可能只是VARCHAR(255)，这种字段要存多行拼接结果十有八九不够。提前在实体类上通过注解指定columnDefinition = "TEXT"，或者建表后手动改字段类型，都能避开后面改表的麻烦。

还有一个常被忽略的点：聚合字段的字符集要和拼接内容一致。MySQL里如果表字符集是utf8mb4，拼接过程中涉及GROUP_CONCAT的内部排序比较时，字符集不一致可能导致报错或乱码，建议库、表、连接都统一用utf8mb4。

5.4 慢SQL排查时的聚合字段排查思路

顺带说一句慢SQL优化。如果一条带字符串聚合的SQL跑得慢，先看执行计划里分组和关联的代价，再看是否因为GROUP_CONCAT处理了大量文本导致排序和临时表开销。有一个经验：可以先用EXPLAIN看Extra列，如果出现Using temporary; Using filesort，说明分组和排序都依赖临时表，数据量大时肯定慢。优化思路有两个，要么给分组字段加索引缩小扫描范围，要么先做预聚合减少输入行数。如果聚合字段很长且不需要排序，可以去掉函数内的ORDER BY，让聚合走更快的哈希分组路径，速度提升明显。

6. 一个真实截断问题的完整排查链路

讲了这么多细节，最后分享一个我实际踩过的截断问题，把排查思路走一遍，以后遇到类似问题可以直接套用。

现象：某个订单导出功能，用MySQL的GROUP_CONCAT拼订单备注，某个订单的明细有几十行，导出的备注字段总是少了中间一段，用LENGTH()检查发现长度固定在1024字节左右，但没有任何报错。

排查第一步：确认是不是group_concat_max_len的限制。执行SHOW VARIABLES LIKE 'group_concat_max_len'，结果是1024，问题基本定位。

排查第二步：确认全局和会话参数差异。SET SESSION group_concat_max_len = 102400后重跑，长度恢复正常。为什么生产环境里修改没生效？因为大多数连接池的连接在初始化时可能没有执行这条SET SESSION，参数只在当前会话内生效，连接复用后很可能还是默认值。

排查第三步：把参数调整固化到配置层面。修改my.cnf里的group_concat_max_len，重启后确认SHOW VARIABLES结果变成新值。

排查第四步：评估字段类型和业务最坏情况。订单明细行数不确定，有的订单能拼到几万字节，虽然有参数兜底，但字段本身如果被写成VARCHAR(500)，结果仍会被截断。因此把存储目标字段改成TEXT，同时在下游导出逻辑里增加长度校验与截断提示。

这个链路看起来简单，但每一步都有对应的验证方法：长度用CHAR_LENGTH()或LENGTH()量，截断位置用SUBSTRING切片对比，参数变化用SHOW VARIABLES确认。遇到类似的“数据莫名少了”问题，我建议按这个顺序排查：先确认字段类型长度，再确认参数限制，再确认拼接函数行为，最后确认下游消费逻辑。顺序反了很容易白忙。

另外，验证多行合并SQL时，我习惯写一个自测SQL，把同一行数据的聚合结果和原始明细行数对照：

SELECT 订单号, COUNT(*) AS 明细行数, LENGTH(GROUP_CONCAT(商品名称 SEPARATOR '、')) AS 聚合长度, GROUP_CONCAT(商品名称 SEPARATOR '、') AS 聚合结果 FROM 订单明细表 GROUP BY 订单号 HAVING COUNT(*) > 1 LIMIT 20;

这样一眼能看出聚合结果是否完整，行数和长度对应上，基本就能排除截断问题。

多行合并到一列这个需求，说难不难，说简单也不简单，真正的门槛全在数据库差异和边界条件上。我自己的习惯是：能输出的结构尽量输出成JSON，能先过滤先过滤，能在子查询里排好序就不要依赖聚合函数的隐藏行为，能提前量好长度就不要事后发现截断。最后一个建议，写这类SQL之前先确认清楚消费方是谁，是Excel、是页面、是接口还是数仓表，这决定了分隔符、长度上限和是否用JSON，把这些想清楚，写出来的SQL基本一遍过。