jsonb_array_elements()用于将JSONB数组展开为多行，返回每行一个元素；需配合类型转换（如::text）和空值过滤确保统计准确，且推荐结合GIN索引提升性能。
PostgreSQL 中用 jsonb_array_elements() 展开 JSON 数组
PostgreSQL 的 jsonb 类型支持原生数组展开，但必须用 jsonb_array_elements()（不能用 json_array_elements()，后者不支持 jsonb 且易报错）。这个函数返回一行一元素的集合，可直接用于 JOIN 或子查询。
常见错误是把字段当普通数组处理，比如写 WHERE tags @> '"python"' 想匹配含 python 的数组——这只能查整个数组是否包含该字符串，无法对每个元素做聚合。真要统计各标签出现次数，必须先展开。
- 确保字段类型是
jsonb：ALTER TABLE posts ALTER COLUMN tags TYPE jsonb USING tags::jsonb - 展开后别忘了加别名，否则后续
GROUP BY会报错：jsonb_array_elements(tags) AS tag - 如果数组可能为
NULL或空，jsonb_array_elements()会跳过整行；需要保留原始行时，改用LEFT JOIN LATERAL jsonb_array_elements(tags) AS tag
MySQL 8.0+ 用 JSON_TABLE() 替代传统 JOIN 展开
MySQL 没有等价于 jsonb_array_elements() 的标量函数，必须用 JSON_TABLE() ——它本质是把 JSON 数组“虚拟建表”，语法稍重但可控性强。注意：只在 MySQL 8.0.4+ 支持，低版本只能靠应用层解析或自定义函数。
典型错误是路径写成 "$[*]" 却没指定列定义，导致返回空结果；或者误用 JSON_EXTRACT() 套多层括号，性能极差。
- 路径必须用双引号包裹，且数组索引写法是
"$[*]"，不是"$.tags[*]"（除非嵌套更深） -
COLUMNS子句里要用PATH显式声明提取路径，例如name VARCHAR(50) PATH "$" - 若原 JSON 是
["a","b"]，JSON_TABLE(tags, "$[*]" COLUMNS(name TEXT PATH "$"))才能正确映射
聚合统计前先处理数据类型与空值
展开后的元素默认是 jsonb（PG）或 JSON（MySQL），不能直接 GROUP BY 或 COUNT。必须显式转成基础类型，否则会得到“不同格式但语义相同”的分组，比如 "python" 和 python（无引号）被当成两个值。
另外，前端传来的 JSON 数组常混入空字符串、null 元素或空白格，不清洗会导致统计偏差。
- PostgreSQL：用
tag::text或trim(tag::text, '"')去掉双引号；过滤空值加WHERE tag::text != 'null' AND trim(tag::text, '"') != '' - MySQL：用
CAST(name AS CHAR)转字符串；空值判断写WHERE name IS NOT NULL AND name != '' - 聚合时建议加
HAVING COUNT(*) > 1排除噪声标签，尤其当用户可自由输入标签时
避免 N+1 查询陷阱：一次展开 + 多维度聚合
有人习惯先查出所有带 tags 的记录，再在代码里循环解析 JSON 数组——这在百万级数据下必然超时。正确做法是在 SQL 层完成展开和聚合，让数据库引擎做最擅长的事。
另一个易错点是写多个独立子查询分别统计不同标签，导致重复展开数组，性能翻倍下降。应统一展开后用 CASE WHEN 分条件计数。
- 单次展开即可支持多维统计：例如同时算
COUNT(*)、COUNT(DISTINCT post_id)、AVG(post_score) - 想按时间窗口统计？在展开前先
WHERE created_at >= '2024-01-01'，别让展开吞下全量历史数据 - 若需高频查询，给
jsonb_path_ops索引加速展开（PG）：CREATE INDEX idx_posts_tags ON posts USING GIN (tags jsonb_path_ops)
JSON 数组展开本身不难，难的是展开后怎么不丢数据、不错类型、不拖慢查询——关键就在那几处类型转换和空值判断，漏一个，统计结果就不可信。
