是，ARRAY_AGG 默认将 NULL 值纳入数组，生成如 {1, NULL, 3} 的结果，易导致 UNNEST 或 @> 等操作异常；推荐用 FILTER (WHERE col IS NOT NULL) 显式过滤，并务必指定 ORDER BY 保证顺序稳定。
ARRAY_AGG 会把 NULL 值也塞进去吗
会，ARRAY_AGG 默认不忽略 NULL —— 如果某行对应字段是 NULL，结果数组里就真有一个 NULL 元素。这常导致后续用 UNNEST 或 @> 判断时行为异常。
- 加
WHERE col_name IS NOT NULL过滤（推荐，语义清晰） - 或用
ARRAY_AGG(col_name) FILTER (WHERE col_name IS NOT NULL)（更灵活，尤其多字段聚合时可分别过滤） - 注意：不能写成
ARRAY_AGG(COALESCE(col_name, ''))来“兜底”，因为类型必须一致 —— 比如col_name是INT，''就会报错cannot cast type text to integer
排序不稳定？记得显式用 ORDER BY
ARRAY_AGG 不保证顺序，哪怕源表有 ORDER BY 或主键。不指定 ORDER BY 子句，每次查询返回的数组元素顺序可能不同 —— 这在比对结果、调试或依赖顺序的业务逻辑（比如取第一个非空值）中很危险。
- 正确写法：
ARRAY_AGG(col_name ORDER BY sort_col) - 支持多列排序：
ARRAY_AGG(col_name ORDER BY status DESC, updated_at ASC) - 如果排序字段本身可能为
NULL，记得补NULLS LAST或NULLS FIRST，否则 PostgreSQL 默认把NULL排最前，容易误判
聚合大文本或 JSON 字段时性能掉得厉害
当 ARRAY_AGG 处理的是长文本（如 TEXT）、JSONB 字段，或分组后单组数据量极大（比如 10 万行聚成一个数组），内存占用和执行时间会明显上升，甚至触发 ERROR: out of memory。
- 先确认是否真需要全部明细：能用
COUNT(*)、STRING_AGG(..., ';')或分页子查询替代，就别硬上ARRAY_AGG - 加索引加速排序：如果用了
ORDER BY，确保排序字段上有索引（特别是复合索引含GROUP BY字段） - 避免在视图或物化视图里无条件用
ARRAY_AGG—— 它没法被下推或剪枝，一查就全量聚合
想拼接字符串但又想保留数组结构怎么办
有时你需要类似 “a,b,c” 的字符串输出，但又怕 STRING_AGG 无法处理嵌套结构（比如字段本身含逗号），或者后续还要转回数组做 @> 查询。这时候别强行用 STRING_AGG，直接用 ARRAY_AGG + 类型转换更稳。
- 转成字符串（带花括号）：
ARRAY_AGG(col_name)::TEXT→ 结果像"{a,b,c}" - 去掉花括号和引号（谨慎！仅限可信数据）：
TRIM(BOTH '"' FROM ARRAY_AGG(col_name)::TEXT)→{a,b,c}，再用REPLACE去掉{} - 真正安全的做法：保持数组类型，前端或应用层调用
array_to_json()或to_jsonb(ARRAY_AGG(...))输出标准 JSON，既免解析歧义，又兼容后续 SQL 操作
数组聚合看着简单，但 NULL 处理、排序控制、数据规模和类型转换这四点，漏掉任一个都可能让结果不可靠或查询崩掉。
