GROUP BY本身不分组后拼接字符串，仅划分组；拼接必须用聚合函数（如STRING_AGG、GROUP_CONCAT、LISTAGG），非分组字段未聚合会报错，且各数据库语法、参数、长度限制及NULL/空字符串处理差异显著。
GROUP BY 后拼接字符串，本质是聚合操作，不是“合并行”
GROUP BY 本身不拼接、不合并字段值，它只划分组；所谓“拼接”，必须搭配聚合函数。直接 SELECT name, hobby FROM users GROUP BY name 会报错，因为 hobby 没有聚合，数据库无法决定取哪一行的值。
常见错误现象包括：Column 'hobby' is invalid in the select list（SQL Server）、Expression not in GROUP BY（PostgreSQL）、或 MySQL 严格模式下的报错。核心原因：非分组字段未经过聚合处理。
- 所有非
GROUP BY字段，必须用聚合函数包裹（如STRING_AGG、GROUP_CONCAT、LISTAGG） - 聚合函数输入是“每组内所有行的该列值”，输出是一个标量（单个字符串）
- 若需拼接多个字段（如
first_name + ' ' + last_name），先在聚合前拼，再进聚合函数，而非对多列分别聚合后试图“合并”
不同数据库拼接函数写法差异极大，不能混用
没有跨库通用的拼接语法。MySQL 用 GROUP_CONCAT，PostgreSQL 和 SQL Server 2017+ 用 STRING_AGG，Oracle 用 LISTAGG。硬套会直接报错，比如在 SQL Server 2016 上写 STRING_AGG 就是 Invalid object name 'STRING_AGG'。
关键参数差异：
-
GROUP_CONCAT(hobby SEPARATOR ' | ' ORDER BY hobby)：分隔符和排序都用关键字指定，DISTINCT可直接加 -
STRING_AGG(hobby, ' | ') WITHIN GROUP (ORDER BY hobby)：分隔符是第二参数，排序必须用WITHIN GROUP，不支持DISTINCT（得先子查询去重） -
LISTAGG(hobby, ' | ') WITHIN GROUP (ORDER BY hobby)：Oracle 写法，类似 SQL Server，但超出 4000 字符要加ON OVERFLOW TRUNCATE
特别注意：STRING_AGG 和 LISTAGG 必须写 ORDER BY 子句，否则结果顺序不确定；而 GROUP_CONCAT 默认按执行顺序拼，但显式写更可靠。
拼接 NULL 值和空字符串的处理方式不一致
各函数对 NULL 的默认行为相同：跳过不参与拼接。但对空字符串 '' 处理不同，容易导致结果意外变长或出现多余分隔符。
- MySQL
GROUP_CONCAT：保留空字符串，GROUP_CONCAT('a', '', 'b' SEPARATOR ',')→a,,b - PostgreSQL
STRING_AGG：也保留空字符串，同上 - SQL Server
STRING_AGG：同样保留，但若字段是TEXT类型，必须先CAST(col AS VARCHAR(MAX))，否则报错
安全做法是提前过滤或替换：STRING_AGG(NULLIF(hobby, ''), ' | ') WITHIN GROUP (ORDER BY hobby)，或用 CASE WHEN hobby = '' THEN NULL ELSE hobby END 包一层。
性能与长度限制常被忽略，线上易出问题
拼接类聚合函数天然有性能开销：每组都要遍历所有行、构造中间字符串、做排序（如果指定了）。更隐蔽的是长度截断风险——它往往静默发生，查不出错，只丢数据。
- MySQL：
group_concat_max_len默认仅 1024 字节，超长被截断无提示；需提前设大：SET SESSION group_concat_max_len = 1000000 - PostgreSQL：
STRING_AGG无硬限制，但内存压力随组内行数线性增长，大数据量组易 OOM - SQL Server：
STRING_AGG输出为VARCHAR(MAX)或NVARCHAR(MAX)，但若源列是TEXT/NTEXT，不CAST就失败
真正容易被忽略的点：字符集和排序规则。比如 MySQL 表用 utf8mb4，但客户端连接用 latin1，拼接结果可能乱码——这不是函数问题，是连接层配置没对齐。
