存储过程不适合实现工作流状态流转，因其缺乏事件上下文、无法处理并发冲突、禁止i/o操作、硬编码路径难维护，仅适合校验合法性、补全字段和轻量聚合。

不能在存储过程中用 SQL 逻辑实现工作流的状态流转——它不是干这个的。

为什么存储过程不适合做状态流转决策

存储过程没有事件上下文，无法知道「谁点了通过」「基于哪条审批规则」「当前是否满足前置条件」。它只能被动执行，而状态流转是主动决策行为。

• 并发时两个审批人同时提交，都查到 CurrentStage = 2，都执行 UPDATE SET CurrentStage = 3，最终只有一条生效，另一条静默失败或覆盖
• MySQL 中若在存储过程里更新同一张表再查（比如先查 approval_steps 再更新 AuditFlow），会直接报 ERROR 1442
• 硬编码转移路径（如 CASE WHEN status = 2 THEN 3）导致每次加 CFO 审批都要 DBA 改存储过程、发版、停服
• 无法发邮件、调 API、写 Kafka —— MySQL/PostgreSQL 的存储过程禁止 I/O；SQL Server 虽支持 xp_cmdshell，但生产环境基本禁用

存储过程能且仅能做的三件事

把它当数据库侧的「守门员」，不是「流程引擎」。所有操作必须是确定性、无副作用、不依赖外部状态的。

极简智能王

一款集合AI聊天、绘画、写作、翻译和编程等能力的综合型AI助手，帮助用户处理多种日常学习与工作任务。

下载

• 校验状态跃迁合法性：比如只允许 OLD.status = 'pending' 且 NEW.status = 'approved_by_mgr' 才允许更新，否则 SIGNAL SQLSTATE '45000'
• 补全冗余字段：自动写入 updated_at、last_approver_id，避免应用层漏传；别在过程里查 users.role 判断权限——把 approver_role 字段冗余进 approval_steps 表
• 轻量聚合生成主表状态：从 approval_steps 查最高通过级，写回 AuditFlow.CurrentStage，但绝不触发下一步动作（比如不 INSERT 下一级待办）

触发器里调用存储过程更新状态？更危险

MySQL 触发器中调用存储过程去改状态，极易撞上 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger —— 尤其是误写 INSERT INTO log_table 这类带隐式提交的操作。

• 触发器职责必须严格限定为「原子性状态变更」：比如把 status 从 'draft' 改成 'pending_first_approval'
• 所有跨系统动作（邮件、IM、回调 API）必须剥离到应用层监听状态变更事件；日志写入也必须和主表更新同事务，不能靠触发器单独 INSERT
• 别用 MAX(level) 判断流程终点——应查配置表获取当前流程总级数，否则某级被跳过会导致状态卡死

真正该由应用层控制的几个关键点

状态流转不是数据库该扛的活，而是应用最该收口的地方。哪怕用最简方案，也要守住这几条线：

• 更新必须带 WHERE current_status = ? 条件，执行后检查 ROW_COUNT() 是否为 1；为 0 说明状态已变，业务应拒绝并提示「操作冲突」
• 状态字段用 TINYINT 而非 ENUM 或 VARCHAR，注释写明含义：COMMENT '0:待提交,1:审核中,2:已通过,3:已拒绝'
• 合法转移路径抽成配置或代码逻辑，比如建一张 state_transition(from_status,to_status,event,allowed) 表，运行时查表校验
• 多级审批必须用关联表 approval_steps，而非在主表硬塞 first_approver_id、second_approver_id 字段

最容易被忽略的，是把「数据库能做什么」和「业务需要什么」混为一谈——存储过程能校验、能补字段、能聚合，但它没法替你做决定。一旦开始在过程里写 IF ... THEN UPDATE ... ELSE INSERT ... 这类带分支的流转逻辑，就已在技术债上签字了。