PostgreSQL中需用jsonb_array_elements()展开JSONB数组后分组，因GROUP BY不支持复合类型；须配合LATERAL关联、外层按原始主键再GROUP BY，并注意空数组处理、索引优化及聚合结果类型匹配。
用 jsonb_array_elements() 展开数组再分组
PostgreSQL 无法直接对 JSONB 数组字段 GROUP BY，因为数组是复合类型，而 GROUP BY 只接受标量值。写 GROUP BY data->'items' 不仅逻辑错误（会把整个数组结构当分组键），还可能因二进制表示差异导致本该合并的组被拆开。
必须先“炸开”数组：用 jsonb_array_elements() 把每个元素转成一行，再通过 LATERAL 关联原记录。注意它只接受 jsonb 类型输入，若字段是 json，得先加 ::jsonb 转换。
- 空数组或
NULL字段调用该函数会导致整行丢失——默认行为，如需保留，得改用LEFT JOIN LATERAL ... ON true并配合COALESCE - 若数组里存的是对象（如
[{"sku":"A","qty":2}]），展开后用elem->>'sku'提取字段；若存字符串（如["tag1","tag2"]），优先用jsonb_array_elements_text()直接得text，省去类型转换 - 别漏掉
LATERAL——写成FROM t, jsonb_array_elements(t.data->'items')是隐式CROSS JOIN LATERAL，但显式写出更安全、可读性更强
聚合前按原始主键 GROUP BY 才不串行
展开后行数会倍增（一个订单含 5 个 item 就变 5 行），如果直接在展开层做 SUM(elem->>'qty')::int，结果会跨订单混算。必须在外层再套一次查询，以原始记录 ID（如 order_id）为分组依据。
- 错误写法：
SELECT SUM((elem->>'qty')::int) FROM orders, LATERAL jsonb_array_elements(items) AS elem—— 没有GROUP BY，只返回一个总和 - 正确结构：先展开 → 得到
order_id,sku,qty宽表 → 外层GROUP BY order_id配合SUM(qty)或COUNT(DISTINCT sku) - 若还需保留订单其他字段（如
created_at），要么加进GROUP BY，要么用MIN(created_at)包裹——PostgreSQL 不允许 SELECT 中出现未分组又非聚合的列
WHERE 条件写法决定索引是否生效
想筛选“含某个 item 的订单再聚合”，别用 data->>'items' LIKE '%sku_A%' 这类字符串匹配——GIN 索引完全无效，且易误匹配。真正能走索引的是语义化操作符。
- 推荐写法：
WHERE data @> '{"items": [{"sku": "A"}]}'，配合CREATE INDEX ON orders USING GIN (data)（用jsonb_path_ops更紧凑） - 避免写法：
WHERE (data->'items'->0->>'sku') = 'A'—— 路径固定，无法利用索引加速；WHERE (data->>'items')::jsonb @> ...—— 强转后表达式索引难命中 - 如果聚合后还要从结果里取字段（如
(jsonb_agg(items))->0->>'sku'），那纯属运行时计算，索引毫无作用——这点容易被忽略
聚合结果类型决定后续提取方式
jsonb_agg() 返回数组，jsonb_object_agg() 返回对象，后续用 ->/->> 提取时，结构错配会静默返回 NULL。
- 从聚合数组取第一个元素：
(jsonb_agg(elem))->0，注意括号——jsonb_agg(elem)->0因运算符优先级等价于jsonb_agg(elem->0)，会报错 - 聚合空数组输入时，
jsonb_agg()返回NULL，不是[]；要空数组请包一层COALESCE(jsonb_agg(elem), '[]'::jsonb) - 如果数组元素本身是
NULL（JSON 字面量null），jsonb_agg()会跳过它，不会插入null元素——这是 SQL 聚合惯例，但业务上是否合理得自己判断
