ARRAY_AGG默认包含NULL且不保证顺序，易致后续处理错误；应使用FILTER(WHERE col IS NOT NULL)去空、ORDER BY确保排序稳定、预估内存避免OOM，并优先选用JSON_AGG替代组合转换。
ARRAY_AGG 会把 NULL 值也塞进数组里
默认行为下，ARRAY_AGG 不过滤 NULL，比如 SELECT ARRAY_AGG(col) FROM t 遇到 col 有 NULL，结果数组里就真有个 NULL 元素。这常导致后续 UNNEST 或 JSON 转换出错，或让应用层空值判断变复杂。
实操建议：
- 明确需要排除空值时，加
FILTER (WHERE col IS NOT NULL)—— 这是 PostgreSQL 9.4+ 支持的标准写法 - 别用
WHERE col IS NOT NULL提前过滤整行，那会丢掉该分组其他非空字段的上下文 - 若字段类型不一致（如混合
TEXT和INTEGER），聚合前必须显式转成同一类型，否则报错ERROR: column "col" has pseudo-type unknown
排序不稳定会导致每次查询结果顺序不同
ARRAY_AGG 本身不保证元素顺序，尤其在并行执行或数据重分布后。看起来“刚好有序”，其实是巧合，上线后可能突然乱序，前端渲染或 diff 对比就会出问题。
实操建议：
- 必须加
ORDER BY子句：例如ARRAY_AGG(name ORDER BY created_at DESC) - 排序字段要能唯一确定顺序；如果
created_at可能重复，得补上主键如ORDER BY created_at DESC, id DESC - 避免在
ORDER BY里用函数或表达式（如LOWER(name)），除非你确认性能可接受——它会让索引失效，且无法利用物化路径优化
聚合大结果集时内存溢出（out of memory）
当某一分组对应上千行、每行字符串又很长（比如日志片段），ARRAY_AGG 会一次性把所有值加载进内存组装数组。PostgreSQL 15 默认 work_mem 是 4MB，很容易触发 ERROR: out of memory 或严重拖慢查询。
实操建议：
- 先用
COUNT(*)粗筛分组大小，对超限分组改用流式处理（如游标 + 应用层拼接） - 临时调高
work_mem仅对该查询生效：SET LOCAL work_mem = '64MB';，但别全局设高，会挤占并发连接内存 - 考虑替代方案：如不需要完整数组，用
STRING_AGG(col, ',')占用更少内存；或用JSON_AGG更适合 Web API 输出
和 JSON 类型混用时类型隐式转换容易翻车
想把 ARRAY_AGG 结果转成 JSON 数组？直接 TO_JSON(ARRAY_AGG(...)) 看似可行，但遇到 NUMERIC、DATE 或自定义类型时，PostgreSQL 15 的 JSON 函数可能拒绝转换或输出意外格式（比如把 numeric 变成字符串）。
实操建议：
- 优先用原生
JSON_AGG替代组合：它专为 JSON 设计，自动处理类型映射，且支持ORDER BY和FILTER - 若必须用
ARRAY_AGG后转 JSON，先用CAST显式归一化类型，例如TO_JSON(ARRAY_AGG(col::TEXT)) - 注意
JSON_AGG默认把NULL转成 JSONnull，而ARRAY_AGG+TO_JSON会保留 SQLNULL导致整个数组为NULL—— 行为差异很隐蔽
实际用的时候，最常被忽略的是排序稳定性与 NULL 处理的组合影响：一个没加 ORDER BY 的 FILTER 查询，在开发环境跑得顺，到了生产数据量大、开启并行后顺序就变了，连带测试断言失败。别依赖“看起来没问题”。
