MySQL用GROUP_CONCAT、PostgreSQL用STRING_AGG，语法行为差异大：MySQL默认截断1024字符、需SET SESSION调长，NULL被跳过；PG必须显式指定分隔符和ORDER BY子句，支持窗口函数但旧版不兼容ORDER BY与OVER共用。
MySQL 用 GROUP_CONCAT，PostgreSQL 用 STRING_AGG，两者语法和行为差异不小，混用会直接报错或结果异常。
MySQL 中 GROUP_CONCAT 的常见陷阱
它默认只拼接前 1024 字符，超长会被无声截断；另外不加 ORDER BY 时顺序不确定，不是按插入顺序也不是主键顺序。
- 用
GROUP_CONCAT(col ORDER BY id SEPARATOR ', ')显式控制顺序和分隔符 - 调大长度限制：执行
SET SESSION group_concat_max_len = 1000000;（注意是 session 级，不是全局） - 遇到 NULL 值会跳过——如果想显示为
'(null)'，得先用IFNULL(col, '(null)')包一层 - 不能直接在子查询的
SELECT列表里嵌套另一个GROUP_CONCAT，会报错“Invalid use of group function”
PostgreSQL 中 STRING_AGG 的关键参数
STRING_AGG 必须显式指定分隔符，且排序必须写在 ORDER BY 子句里（不能像 MySQL 那样塞进函数参数里）。
- 基本写法：
STRING_AGG(col, ', ' ORDER BY id)—— 注意逗号后是分隔符，ORDER BY是独立子句 - 处理 NULL：
STRING_AGG(COALESCE(col, '(null)'), ', ' ORDER BY id)，COALESCE比NULLIF更常用 - 若想保留重复值，不用额外操作；但要去重，得先套一层子查询或 CTE 去重再聚合
- 在窗口函数中也能用：
STRING_AGG(col, ', ') OVER (PARTITION BY category)，但不能同时带ORDER BY和OVER（PG 15+ 支持，旧版不支持）
跨数据库兼容的替代思路
如果代码要同时跑在 MySQL 和 PG 上，别硬套这两个函数——它们没有标准 SQL 对应物，强行抽象容易翻车。
- 应用层拼接更可控：查出多行后由 Python/Java 等做
join()，尤其适合拼接逻辑复杂（如带条件、嵌套结构）的场景 - 用 JSON 聚合过渡：
JSON_ARRAYAGG(col)（MySQL 5.7+/PG 9.4+）返回数组，再由上层解析，避免分隔符转义问题 - 视图或中间表预聚合：对高频使用的拼接结果建物化视图（PG）或定时刷新的汇总表（MySQL），换空间换时间
最常被忽略的是字符集隐式转换：GROUP_CONCAT 结果类型依赖第一个非 NULL 参数的字符集，如果混用 utf8mb4 和 latin1 字段，可能触发截断或乱码；STRING_AGG 虽强制同字符集，但输入列若含 bytea 或 text 类型，仍需提前 CONVERT_TO(col::text, 'UTF8')。这类问题往往在线上数据量变大后才暴露。
