怎么在SQL中通过嵌套查询实现多级审批流状态追踪-SQL-PHP中文网

嵌套查询无法建模审批流层级关系，必须用with recursive递归查询（适用于流程定义表）或窗口函数（如lag/lead，适用于日志表）来追踪路径与卡点，同时需注意角色变更、状态枚举一致性及递归深度限制。

怎么在sql中通过嵌套查询实现多级审批流状态追踪

嵌套查询无法直接建模审批流状态，得用递归或窗口函数

SQL 的标准嵌套查询（SELECT ... FROM (SELECT ...) AS sub）本质是单层派生表，它拿不到“上一审批人是谁”“当前节点在第几级”这类层级关系。真要追踪多级审批流（比如：申请人 → 部门主管 → 财务 → 总监 → CEO），靠一层套一层的子查询不仅写起来爆炸，而且查到第 5 级就得嵌 5 层，维护和理解成本极高。

真正可行的路径只有两条：WITH RECURSIVE（PostgreSQL / SQL Server / SQLite 3.35+ / MySQL 8.0+）做自引用递归，或者用 ROW_NUMBER() / LAG() 等窗口函数按时间/顺序排序后逐行比对。前者适合树状结构明确的审批定义表，后者更适合记录已发生的审批动作日志表。

用 WITH RECURSIVE 追溯审批路径（以 PostgreSQL 为例）

假设你有两张表：approval_flows 定义流程模板（谁审谁、顺序、是否并行），approval_logs 记录每次审批的实际操作。要查某次申请的完整审批链及当前卡点，不能只查 approval_logs —— 它缺“下一步该谁审”的逻辑，必须结合流程定义。

WITH RECURSIVE flow_path AS ( SELECT id, approver_role, order_seq, NULL::text AS prev_role FROM approval_flows WHERE flow_id = 'PO_APPROVAL' AND order_seq = 1 UNION ALL SELECT f.id, f.approver_role, f.order_seq, fp.approver_role FROM approval_flows f INNER JOIN flow_path fp ON f.flow_id = fp.flow_id AND f.order_seq = fp.order_seq + 1 ) —— 先把整条流程从头到尾拉出来
再 LEFT JOIN approval_logs l ON l.flow_id = 'PO_APPROVAL' AND l.approver_role = flow_path.approver_role AND l.request_id = 'REQ-2024-789'，就能看出哪一级有记录、哪一级还没走
关键点：order_seq 必须严格连续且唯一，否则递归会断；如果存在“财务或法务任一通过即进入下一级”，就得先用 UNION 拆成两条路径，不能硬塞进单条递归

用窗口函数分析审批日志中的状态断点

如果你只有 approval_logs 表（无预定义流程表），但每条记录含 request_id、approver_id、status（'approved'/'rejected'/'pending'）、created_at，那得靠排序和偏移来识别卡点：

SELECT
  request_id,
  approver_id,
  status,
  created_at,
  LAG(status) OVER (PARTITION BY request_id ORDER BY created_at) AS prev_status,
  LEAD(status) OVER (PARTITION BY request_id ORDER BY created_at) AS next_status
FROM approval_logs
WHERE request_id = 'REQ-2024-789';

这样能一眼看出：上一人批了，下一人还没动（next_status IS NULL），且当前是 pending，那就是卡在这里；如果当前是 rejected，prev_status 是 approved，说明是中途驳回。注意：ORDER BY created_at 前提是审批严格按时序发生——现实中多人可能同时点“通过”，得加一个更稳的排序字段，比如数据库自增 id 或带毫秒的时间戳。

容易被忽略的三个现实坑

实际跑通审批流查询，光语法对不够：

审批人可能变更（A 被调岗，B 代理其角色），但日志里还记着 approver_id = 'A' —— 这时光靠 JOIN users 查不到 B，得额外关联 approver_assignments 表查生效时间段
status 字段如果允许空值或写错（如写成 'Approve' 而非 'approved'），CASE WHEN status = 'approved' 就会漏数据；建议用枚举类型或检查约束提前锁死取值
递归查询默认有 100 层深度限制（PostgreSQL max_recursion_depth），超长流程（比如跨国多级合规审查）会报 ERROR: stack depth limit exceeded，必须显式加 MAXRECURSION 500（SQL Server）或调大配置（PG 需改 statement_timeout 和 work_mem）