不能直接 group by regexp_matches() 的结果，因为其返回 text[] 数组类型，postgresql 不支持对数组进行等值比较和分组；必须用 cross join lateral 与 regexp_matches 结合并取 tag[1] 等捕获组展开为标量后才能聚合。
直接回答：用 regexp_matches 提取匹配项后，再用 GROUP BY 或窗口函数聚合；但注意它返回的是数组，不能直接 GROUP BY，得先展开。
为什么不能直接 GROUP BY regexp_matches() 的结果？
regexp_matches 返回的是 text[]（文本数组），比如 {'abc'} 或 {'user', '123'}。PostgreSQL 不允许对数组类型直接 GROUP BY（会报错 ERROR: could not determine data type of parameter $1 或类似提示），更别说按捕获组内容分组了。
- 常见错误现象：
SELECT regexp_matches(desc, 'user(\d+)'), COUNT(*) FROM logs GROUP BY regexp_matches(desc, 'user(\d+)');→ 报错 - 根本原因：数组不是标量，无法参与等值比较，
GROUP BY无法判断两个数组是否“相等” - 正确路径：必须先把数组“展开”成行，再聚合
如何把 regexp_matches 结果转成可分组的字段？
用 UNNEST 配合 LATERAL 展开结果，让每条匹配生成一行 —— 这是唯一稳定、可读性强的做法。
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 示例：提取所有
#标签并统计频次 SELECT tag[1] AS hashtag, COUNT(*)<br>FROM logs<br>CROSS JOIN LATERAL regexp_matches(content, '#([A-Za-z0-9_]+)', 'g') AS tag<br>GROUP BY tag[1];
-
tag[1]是取第一个捕获组（即括号里匹配的内容）；没括号就用tag[0]取整个匹配 -
'g'标志必须加，否则只匹配第一个，UNNEST就没意义了 - 不用
CROSS JOIN LATERAL而用子查询会出错或漏数据 —— 因为regexp_matches在子查询中可能被优化掉或不重复执行
想按多个捕获组分别统计？别嵌套，拆开写
比如日志里有 user=alice,level=error,code=500，想分别统计 user、level、code 的分布 —— 别试图在一个 regexp_matches 里全抓完再分列，容易错位或空值干扰。
- 正确做法：对每个维度单独写一次
regexp_matches+LATERAL - 例如统计 level：
SELECT lvl[1] AS level, COUNT(*)<br>FROM logs<br>CROSS JOIN LATERAL regexp_matches(log_line, 'level=([^,]+)', 'g') AS lvl<br>GROUP BY lvl[1];
- 如果硬要合并到一个查询里，用多个
LATERAL（顺序无关，但每行都会触发一次正则扫描） - 性能影响：每次
LATERAL都重跑一遍正则；大数据量时，比预处理成新列慢 2–5 倍
替代方案：用 regexp_replace 或 split_part 更快？
如果只是简单分隔（如按固定字符切分），split_part 或 string_to_array 比正则快得多；但只要涉及模式识别（比如“提取所有邮箱”“匹配带前缀的 ID”），regexp_matches 就不可替代。
-
split_part('a,b,c', ',', 2)→'b'，快且确定 -
regexp_matches('id:U123, id:A456', 'id:([A-Z]\d+)', 'g')→ 必须用正则，split_part无能为力 - 容易踩的坑：用
regexp_replace“清洗后计数”看似简单，但会丢失原始匹配上下文（比如你不知道替换掉了几个） - 真正需要分组统计匹配内容时，
regexp_matches+LATERAL+UNNEST是唯一可靠组合
最常被忽略的一点：regexp_matches 默认只返回第一个匹配，忘了加 'g' 标志会导致统计严重偏低 —— 特别是在日志类多匹配场景下，这个标志不是可选，是刚需。
