postgresql和sql server的string_agg必须显式声明order by，否则因函数签名不匹配而报错；mysql的group_concat排序也须写在函数内，外部order by无效，且默认长度限制1024字符，超长会静默截断。
STRING_AGG 必须显式写 ORDER BY，否则直接报错
PostgreSQL 和 SQL Server 的 STRING_AGG 不接受无序拼接。漏掉排序子句会触发类似 ERROR: function string_agg(text) does not exist 的错误——不是语法错，而是函数签名不匹配：它只认 STRING_AGG(expr, sep ORDER BY ...) 这种完整形式。
常见误写：STRING_AGG(name, ', ')（缺 ORDER BY） → 报错；STRING_AGG(name, ', ') ORDER BY id（把 ORDER BY 写在函数外） → 无效，仍报错。
- PostgreSQL 正确写法：
STRING_AGG(name, ', ' ORDER BY created_at DESC) - SQL Server 正确写法：
STRING_AGG(name, ', ') WITHIN GROUP (ORDER BY created_at DESC) - 分隔符必须是字符串字面量或确定表达式，不能是列名或 NULL
GROUP_CONCAT 排序必须写在函数内部，外部 ORDER BY 无效
MySQL 的 GROUP_CONCAT 表面宽松，实则更隐蔽：如果只在语句末尾加 ORDER BY，对拼接结果顺序**完全不起作用**。引擎可能按索引、缓存或数据物理顺序返回，换环境就变。
正确做法是把排序逻辑塞进函数参数里：
-
GROUP_CONCAT(name ORDER BY updated_at DESC)—— 按时间倒序拼 -
GROUP_CONCAT(DISTINCT status ORDER BY status)—— 去重 + 字典升序 - 自定义分隔符用
SEPARATOR ' | '，例如：GROUP_CONCAT(name ORDER BY id SEPARATOR ' → ') - 默认长度限制 1024 字符，超长静默截断；需提前设：
SET SESSION group_concat_max_len = 10000
NULL 值处理逻辑因数据库而异，不能假设一致
同一字段含 NULL 时，三个主流数据库行为完全不同：
- PostgreSQL：
STRING_AGG默认跳过 NULL 行，无需额外处理 - SQL Server：
STRING_AGG默认把 NULL 当作空字符串拼入，可能产生多余分隔符（如a,,b），建议前置过滤：WHERE name IS NOT NULL或统一转空：STRING_AGG(ISNULL(name, ''), ', ') WITHIN GROUP (...) - MySQL：
GROUP_CONCAT同样跳过 NULL，但若想保留占位，得用COALESCE(name, 'NULL') - 想让 NULL 显式显示为字符串，所有场景都应先用
COALESCE(col, 'NULL')或ISNULL(col, 'NULL')预处理
跨数据库兼容性差，动态排序或条件拼接建议移至应用层
当排序依据是变量（如用户传参的字段名）、或需按不同条件分支拼接（比如“状态=已发货时按物流单号排，否则按创建时间”），SQL 层很快失控：
- PostgreSQL 不支持在
ORDER BY子句中用 CASE 表达式动态选列（会报错） - SQL Server 的
WITHIN GROUP也不允许表达式作为排序键 - MySQL 的
GROUP_CONCAT虽支持CASE，但嵌套深了可读性极差，且无法规避长度限制风险 - 大数据量下聚合函数易触发内存溢出或超时，尤其配合复杂排序时
真正需要灵活性和健壮性的地方，不如在应用代码里 fetch 多行后做 sort + join —— 控制力更强，调试更直观，也避开各数据库拼接函数那些互不兼容的坑。
