STRING_AGG中ORDER BY必须写在函数括号内且紧贴分隔符后，如STRING_AGG(name, ', ' ORDER BY created_at)；外部ORDER BY无效，漏括号、颠倒参数、误用SQL Server语法均报错；排序字段须属GROUP BY列或聚合表达式；NULL默认排最前，应显式指定NULLS LAST；旧版PostgreSQL需用ARRAY_AGG替代；不加ORDER BY则顺序不确定。
STRING_AGG里ORDER BY必须写在括号内、紧贴分隔符之后
很多人写成 STRING_AGG(name, ', ') ORDER BY created_at，结果拼出来的字符串顺序完全没变——因为这是对外层查询结果排序，跟聚合内部的拼接顺序无关。真正起作用的写法是把 ORDER BY 塞进函数括号里，和分隔符并列：STRING_AGG(name, ', ' ORDER BY created_at)。
常见错误包括：
- 漏掉右括号：
STRING_AGG(name, ', ' ORDER BY id DESC→ 报错：syntax error at or near “)” - 把分隔符和表达式顺序颠倒：
STRING_AGG(', ', name)→ 报错：function string_agg(unknown, text) does not exist - 在SQL Server风格下硬套语法：
STRING_AGG(name, ', ') WITHIN GROUP (ORDER BY id)→ PostgreSQL 不认这个写法
排序字段只能引用GROUP BY列或聚合表达式
你在 GROUP BY department_id 的前提下，ORDER BY 里能用的字段很有限：
- ✅ 允许：
STRING_AGG(name, '; ' ORDER BY name)（name是非聚合列，但属于分组维度内的确定值） - ✅ 允许：
STRING_AGG(name, '; ' ORDER BY LENGTH(name) DESC)（表达式只依赖当前行的name） - ✅ 允许：
STRING_AGG(name, '; ' ORDER BY MAX(salary) DESC)（MAX(salary)是合法聚合） - ❌ 报错：
STRING_AGG(name, '; ' ORDER BY email)（email没出现在GROUP BY里，也不是聚合结果）
如果字段来自 JOIN 表，务必加表别名或前缀，避免歧义，比如 ORDER BY u.created_at 而不是裸写 created_at。
NULL值默认排最前，不处理会干扰业务逻辑
STRING_AGG 本身跳过 NULL 值（不参与拼接），但 ORDER BY 子句仍会对它们计算位置。默认行为是 NULLS FIRST，这意味着哪怕最终字符串里没有 NULL，排序时它仍可能把非空值“挤”到后面。
典型场景：按 nickname 拼接用户昵称，部分为空。不加控制时，结果可能是 "Alice, Bob"，但若某次执行中空值恰好影响了排序锚点，就可能变成 "Bob, Alice" —— 看似一致，实则不可靠。
解决方式很简单：
- 统一置后：
STRING_AGG(nickname, ', ' ORDER BY nickname NULLS LAST) - 显式替换：
STRING_AGG(COALESCE(nickname, 'unnamed'), ', ' ORDER BY nickname NULLS LAST)
性能和兼容性：老版本不支持、大分组慎用复杂排序
STRING_AGG(... ORDER BY ...) 是 PostgreSQL 9.0+ 原生支持的语法，8.4 及更早版本会直接报错：syntax error at or near "ORDER"。如果要兼容旧环境，得退化为：array_to_string(ARRAY_AGG(name ORDER BY created_at), ', ')。
排序本身有开销，尤其当单个分组包含上千行时：
- 优先选已建索引的字段排序，比如主键
id或带索引的时间字段created_at - 避免在
ORDER BY里用函数：如LOWER(name)或REPLACE(name, ' ', '')，除非业务强依赖 - 拼接结果过长时，数据库不会自动截断；建议外层包
LEFT(..., 1000)或由应用层控制长度
最易被忽略的一点：不写 ORDER BY 时，结果顺序完全不确定——并行查询、VACUUM、甚至 minor 版本升级都可能导致顺序突变。线上环境千万别赌“这次看起来是有序的”。
