触发器能自动跳转审批状态吗？不能，但可以辅助状态变更
MySQL 触发器本身不支持“跳转”逻辑，它只是在 INSERT、UPDATE 或 DELETE 发生时被动执行一段 SQL。所谓“多级审批流的状态自动跳转”，本质是：当某一级审批完成（比如把 status 改为 'approved_by_mgr'），就检查是否满足下一级条件（如所有前置审批字段非空、时间戳已更新），然后自动把 status 更新为下一级值（如 'approved_by_hr'）。触发器能做的是这个“检查 + 更新”，不是流程引擎式的跳转。
用 BEFORE UPDATE 触发器拦截并修正状态值
必须用 BEFORE UPDATE，而不是 AFTER UPDATE —— 因为只有前者允许你修改即将写入的新行数据（通过 NEW.status）。如果用 AFTER，状态已经落库，再改就得额外发一次 UPDATE，可能引发递归或死锁。
- 触发器要限定作用于审批表（如
approval_records），且只响应status字段被显式更新的场景 - 判断逻辑必须明确：比如当前
OLD.status = 'pending'且NEW.status = 'approved_by_mgr'，同时NEW.mgr_approval_time IS NOT NULL，才允许推进到 HR 审批 - 避免硬编码状态字符串，建议用变量或查配置表（但 MySQL 触发器不支持子查询查普通表，可用
SELECT ... INTO查单行配置，或把规则写死） - 示例片段：
DELIMITER $$ CREATE TRIGGER tr_auto_advance_status BEFORE UPDATE ON approval_records FOR EACH ROW BEGIN IF OLD.status = 'pending' AND NEW.status = 'approved_by_mgr' AND NEW.mgr_approval_time IS NOT NULL THEN SET NEW.status = 'waiting_for_hr'; ELSEIF OLD.status = 'waiting_for_hr' AND NEW.status = 'approved_by_hr' AND NEW.hr_approval_time IS NOT NULL THEN SET NEW.status = 'approved'; END IF; END$$ DELIMITER ;
哪些情况会让触发器失效或出错？
实际部署后最常见的崩点不是语法，而是隐性约束冲突：
-
NEW.status被设为非法值（如'approved_by_ceo'），但触发器没覆盖该分支 → 状态卡住，且无报错 - 多个字段需同时校验（如
mgr_approval_time和mgr_comment都非空），漏判一个就会跳过推进 - 触发器里调用函数返回
NULL，导致整个IF判断为UNKNOWN，逻辑跳过 - 事务中其他语句先更新了同一行，触发器读到的
OLD/NEW是中间态，与业务预期不符 - MySQL 8.0+ 开启了
sql_mode=STRICT_TRANS_TABLES时，SET NEW.xxx = ...若类型不匹配（比如把字符串赋给 INT 字段），会直接报错中断事务
比触发器更稳的替代方案是什么？
纯靠触发器实现多级审批流，在真实业务中容易失控。真正健壮的做法是：把状态推进逻辑收口到应用层事务中，用存储过程封装检查和更新，并在调用前加业务锁（如 SELECT ... FOR UPDATE）。触发器只保留最轻量的兜底校验，比如禁止将 status 从 'approved' 改回 'pending'：
IF OLD.status = 'approved' AND NEW.status != 'approved' THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Cannot revert approved status'; END IF;
复杂审批规则（如“任意两人 approve 即通过”“超时自动升级”）几乎无法在触发器里清晰维护，留到应用代码里处理，反而更容易测试和审计。
