ARRAY_AGG将多行聚合成数组但易踩坑：默认包含NULL、顺序不定、空组返回NULL而非空数组；大数据量时性能差；生成后难展开/更新/索引，仅适合只读汇总。
ARRAY_AGG 会把多行数据聚合成一个数组，但默认行为容易踩坑
直接用 ARRAY_AGG(column) 看似简单，但结果可能和预期不符：NULL 值会被包含进去，顺序不固定，且对空组返回 NULL 而不是空数组。比如执行 SELECT ARRAY_AGG(name) FROM users WHERE id ，结果是 NULL，不是 {} —— 这在应用层处理时容易触发空指针或类型错误。
实操建议：
- 加
ORDER BY显式控制顺序：ARRAY_AGG(name ORDER BY created_at) - 用
FILTER (WHERE ...)预筛数据，比在外部加WHERE更安全（避免漏掉分组键） - 用
COALESCE(ARRAY_AGG(...), ARRAY[]::text[])把 NULL 转为空数组，类型需显式转换匹配
聚合时保留去重、去 NULL 或自定义结构，得靠子查询或表达式包装
ARRAY_AGG 本身不支持 DISTINCT 或 IGNORE NULLS（像 Oracle 那样），但 PostgreSQL 支持在参数里套表达式。常见需求如“每个用户的所有非空邮箱去重后成数组”，不能写 ARRAY_AGG(DISTINCT email)（语法错误），而要写：
ARRAY_AGG(DISTINCT email) FILTER (WHERE email IS NOT NULL)
更复杂的场景，比如把两列拼成 JSON 对象再聚合：
ARRAY_AGG(JSON_BUILD_OBJECT('id', id, 'name', name))
注意：嵌套函数会让执行计划变重，尤其在大表上，建议先确认索引覆盖了 FILTER 条件字段。
和 GROUP BY 搭配时，别忘了所有非聚合字段都必须出现在 GROUP BY 中
这是初学者高频报错点：ERROR: column "x" must appear in the GROUP BY clause or be used in an aggregate function。例如想按部门查员工姓名数组，却漏写了部门字段：
SELECT ARRAY_AGG(name) FROM employees;
这会把全表压成一个数组 —— 如果本意是“每部门一个数组”，就得写：
SELECT dept, ARRAY_AGG(name ORDER BY name) FROM employees GROUP BY dept;
如果还想要部门人数、最早入职时间等，所有非 ARRAY_AGG 字段都得进 GROUP BY，或者改用窗口函数（但那就不是聚合了）。
性能敏感场景下，ARRAY_AGG 可能比 STRING_AGG 慢不少
数组构造比字符串拼接开销更大，尤其当元素多、类型复杂（如 JSON、几何类型）时。用 EXPLAIN ANALYZE 对比过，10 万行数据聚合为 text[] 比 STRING_AGG(..., ',') 慢 2–3 倍。如果下游只是遍历读取，且不需要数组语义（比如 PostgreSQL 特有的数组操作符 @>、&&），优先考虑 STRING_AGG + 应用层解析。
另外，ARRAY_AGG 结果过大（如单个数组超几 MB）会显著拖慢网络传输和客户端内存分配，这时应考虑分页聚合或改用游标流式处理。
真正麻烦的不是语法，而是数组一旦生成，后续想展开、更新、索引都受限 —— 它适合「只读汇总」，不适合「可查询中间态」。
