MySQL中GROUP_CONCAT拼接多字段需用CONCAT组合、处理NULL、设置SEPARATOR和group_concat_max_len；PostgreSQL的STRING_AGG需显式合并字段、指定分隔符、支持ORDER BY和FILTER；SQL Server的STRING_AGG要求类型一致、显式转换、WITHIN GROUP排序；复杂场景建议应用层聚合。
MySQL用GROUP_CONCAT拼接多字段要注意什么
直接拼接多个字段，GROUP_CONCAT 默认只接受单个表达式。想把 name 和 age 一起拼成 “张三-25”，得手动组合，不能写成 GROUP_CONCAT(name, age)——这会报错或被当成多个参数忽略。
- 正确写法是用连接符包裹：例如
GROUP_CONCAT(CONCAT(name, '-', age) SEPARATOR ';') -
SEPARATOR不设默认是逗号，但中文场景常改成'；'或'|'避免和字段内容冲突 - 字段含
NULL会导致整段拼接结果变NULL，加IFNULL(name, '')更稳妥 - 拼接长度受
group_concat_max_len限制（默认1024），超长会被截断，查SHOW VARIABLES LIKE 'group_concat_max_len';，必要时用SET SESSION group_concat_max_len = 1000000;临时调高
PostgreSQL里STRING_AGG怎么处理空值和分隔符
STRING_AGG 比 GROUP_CONCAT 更严格：它不自动跳过 NULL，也不支持直接拼多字段表达式，必须先用 COALESCE 或 || 合并字段。
- 拼两个字段：写成
STRING_AGG(COALESCE(name, '') || '-' || COALESCE(age::text, ''), ';') - 分隔符是必填参数，漏写会报错
function string_agg(unknown) does not exist - 如果想按某字段排序后再拼，必须加
ORDER BY子句：STRING_AGG(..., ';' ORDER BY created_at DESC) - 聚合前用
FILTER (WHERE status = 'active')可实现条件拼接，比子查询更轻量
SQL Server的STRING_AGG兼容性陷阱
SQL Server 2017+ 才有 STRING_AGG，旧版本只能用 FOR XML 或自定义函数。即使新版，也容易踩几个隐性坑：
- 字段类型必须一致，
name是VARCHAR、age是INT，直接name + age会报错，必须显式转成字符串：name + CAST(age AS VARCHAR) -
STRING_AGG不支持NULL值跳过，但也不会让整条结果变NULL——它会把NULL当空字符串处理，这点和 MySQL 不同 - 排序必须用
WITHIN GROUP (ORDER BY ...)，语法位置固定，写在括号外会报错 - 如果目标列是
TEXT类型，STRING_AGG返回的是VARCHAR(MAX)，注意应用层是否兼容
跨数据库通用方案：为什么有时该放弃内置函数
当拼接逻辑复杂（比如带条件、嵌套JSON、去重、多层级分组），硬套 GROUP_CONCAT 或 STRING_AGG 容易写出不可读、难调试的长表达式。这时候不如在应用层聚合。
- 数据库只做分组
SELECT group_id, name, age FROM t GROUP BY group_id, name, age，把原始行拉出来再用 Python/Java 拼接，可控性更强 - 尤其涉及字符编码（如 MySQL 的 utf8mb4 vs 应用层 UTF-8）、特殊符号转义（分号、反斜杠）、性能敏感场景（千万级分组），预处理比 SQL 里硬拼更稳
- 不是所有数据库都支持窗口函数配合拼接，别为了“一条SQL搞定”牺牲可维护性
拼接本身简单，但字段类型、NULL 处理、长度限制、排序依赖这几个点，每换一个数据库就得重新核对一遍。别假设语法一致，执行前先查文档里的函数签名和示例。
