string_agg必须在函数内显式使用order by子句排序，语法为string_agg(expr, delim order by sort_expr)，外层order by无效；排序字段需兼容、null须显式处理，复杂表达式影响性能。
string_agg 本身不支持直接排序，必须配合 ORDER BY 子句
string_agg 是聚合函数，不是普通函数，它的排序能力完全依赖于其内部的 ORDER BY 子句——这个子句写在括号里、逗号之后，而不是放在外部 GROUP BY 语句末尾。很多人第一次写错，就是把排序写成 GROUP BY x ORDER BY y，结果排序无效，拼接顺序仍是物理存储或扫描顺序。
正确语法是：string_agg(expression, delimiter ORDER BY sort_expression)。注意：这里的 ORDER BY 是 string_agg 的一部分，不是 SQL 语句级的子句。
-
expression必须是字符串类型（或可隐式转为text），否则报错function string_agg(character varying, unknown) does not exist - 分隔符（
delimiter）可以是空字符串''，但不能省略；想用空分隔符就显式写'' - 排序表达式（
sort_expression）可以和聚合字段不同，比如按created_at排序但拼接name
多字段排序和 NULL 处理要显式声明
当需要按多个条件排序（如先按状态再按时间），或对 NULL 值有明确要求时，不能依赖默认行为。PostgreSQL 中 NULLS FIRST / NULLS LAST 必须显式写出，否则不同版本或配置下表现可能不一致（尤其在启用 transform_null_equals = on 的旧环境里）。
例如，想让 NULL 名字排最后、同名按更新时间倒序：
string_agg(name, ', ' ORDER BY name NULLS LAST, updated_at DESC)
- 不写
NULLS LAST时，name IS NULL的行可能被挤到最前，导致拼接结果开头出现冗余逗号 - 排序字段类型需兼容：不能对
jsonb字段直接ORDER BY，得先用->>提取为文本 - 若排序字段有重复值，最终拼接顺序仍由底层 tuple tid 决定，不保证稳定 —— 如需绝对稳定，应加入主键作为第二排序项
性能敏感场景慎用复杂排序表达式
在大表上对每组执行表达式计算（如 lower(name)、substring(email, '@.*$')）再排序，会显著拖慢聚合速度。PostgreSQL 无法将这类表达式下推到物化阶段优化，相当于对每个输入行都实时计算一次。
- 高频查询建议提前计算并建索引：比如加生成列
name_lower TEXT GENERATED ALWAYS AS (lower(name)) STORED，再在该列上建索引 - 避免在
ORDER BY里调用 volatile 函数（如now()、random()），会导致结果不可重现，且可能触发重复计算 - 如果只是去重后拼接，
string_agg(DISTINCT ...)不支持内部排序，必须用子查询先ORDER BY再聚合
替代方案：用 array_agg + array_to_string 更灵活
当 string_agg 的语法限制住你（比如想动态传入分隔符变量、或排序逻辑太复杂），用 array_agg 先收集成数组，再转字符串更可控：
SELECT array_to_string(array_agg(name ORDER BY priority, id), ' | ') FROM tasks GROUP BY project_id;
-
array_agg同样支持ORDER BY，且能天然处理DISTINCT和过滤（FILTER (WHERE ...)） -
array_to_string第二个参数支持任意text表达式，包括字段值或 CASE 结果，而string_agg的分隔符必须是常量或简单参数 - 注意内存开销：大组（如单组上万行）生成长数组可能触发 work_mem 不足，报错
ERROR: out of memory for query result
真正麻烦的从来不是语法怎么写，而是排序依据是否稳定、NULL 是否被忽略、以及当数据量涨十倍时那个 ORDER BY lower(name) 还能不能在 200ms 内返回。
