group by 是 sql 查询子句，仅在 select 执行阶段对数据分组并聚合，不参与存储过程调用或控制执行层级；分级逻辑必须由存储过程内部的递归、分支或循环实现，二者属于不同执行平面，不可混用。
GROUP BY 本身不能实现“分级存储过程调用”——它不参与过程调用逻辑，也不控制执行层级。所谓“分级”，必须由存储过程内部的递归调用、条件分支或循环结构实现，GROUP BY 只负责在某一层查询中做聚合统计。
为什么 GROUP BY 和存储过程调用是两件事
GROUP BY 是 SQL 查询子句，只在 SELECT 执行阶段生效，作用于数据行分组与聚合；而存储过程调用（如 CALL 或 SELECT func()）属于过程控制行为，发生在 PL/pgSQL 运行时。两者不在同一执行平面：
- 你在
SELECT ... GROUP BY里无法直接触发另一个存储过程的执行 - 你也不能把
GROUP BY当作“调用分级”的依据——数据库不会因为某行被分到第 3 组就自动调用第 3 层过程 - 若想实现“按分组结果驱动不同逻辑”，必须先查出分组结果（比如用临时表或游标），再在 PL/pgSQL 中遍历处理
真正在用 GROUP BY 配合存储过程的典型场景
常见做法是：先用 GROUP BY 汇总数据，再把汇总结果作为参数传给存储过程做后续处理。例如电商中按区域汇总订单后触发发货策略：
- 先执行
SELECT region, SUM(amount) AS total FROM orders WHERE order_time >= CURRENT_DATE - INTERVAL '7 days' GROUP BY region - 在 PL/pgSQL 中用游标遍历该结果集：
FOR r IN (SELECT ...) LOOP PERFORM dispatch_by_region(r.region, r.total); END LOOP; - 注意：这里
dispatch_by_region是你定义的函数，r.region和r.total是 GROUP BY 输出的字段，不是原始表字段 - 避免在游标循环里做重查询——把 GROUP BY 结果一次性查全，别在每次循环里重复
SELECT ... GROUP BY
容易踩的坑：递归 CTE + GROUP BY + 存储过程混合写法
有人试图在递归 CTE 里嵌套 GROUP BY 再调用过程，结果报错或无限循环。关键问题在于：
-
WITH RECURSIVE的递归支中允许GROUP BY，但只能按父表字段（如p.id）分组，不能按 CTE 自身输出字段（如c.sum_value）分组 - 在递归支里调用存储过程（如
PERFORM update_cache(...)）会导致 PostgreSQL 报cannot execute INSERT/UPDATE/DELETE in a read-only context—— 递归 CTE 默认只读 - 若真需要边聚合边触发逻辑，得拆成两步：先用递归 CTE 生成带层级的聚合结果；再用
DO $$ BEGIN ... END $$块遍历结果并调用过程
替代方案：用 RETURNING + FOR LOOP 实现“类分级”效果
如果你实际想要的是“对每个分组执行一次定制化逻辑”，更可靠的做法是放弃在 SQL 层强行融合，改用显式控制流：
DO $$
DECLARE
r RECORD;
BEGIN
FOR r IN
SELECT dept, COUNT(*) AS cnt
FROM employees
GROUP BY dept
HAVING COUNT(*) > 5
LOOP
-- 每个 dept 对应一次调用
PERFORM notify_dept_lead(r.dept, r.cnt);
END LOOP;
END $$;
这种写法清晰、可控、易调试。真正的“分级”逻辑（比如部门下再分小组、小组下再算人效）应该在 notify_dept_lead 函数内部实现，而不是靠 GROUP BY 推导。
最常被忽略的一点：GROUP BY 的执行时机永远在 WHERE 之后、HAVING 之前，且不感知过程调用。想让它“驱动”什么，必须主动把它拉进 PL/pgSQL 的变量或游标里——数据库不会替你跨层桥接。
