不能可靠做流转决策。MySQL触发器虽能响应增删改自动执行SQL，但无法感知业务上下文、校验旧状态、记录操作人或保证日志与主表原子性，易导致数据不一致；状态流转应由应用层显式控制，并用WHERE条件+ROW_COUNT()校验确保安全性。
触发器能自动更新状态吗？不能可靠做流转决策
MySQL触发器可以响应 INSERT/UPDATE/DELETE 自动执行 SQL，但**不建议用它实现工作流状态流转逻辑**。原因很实际：触发器无法感知业务上下文（比如“谁操作”“基于什么事件”“是否满足前置条件”），也难以校验旧状态、记录操作人、写入日志——这些恰恰是状态流转的核心要求。
常见错误现象：BEFORE UPDATE 触发器里直接 SET NEW.status = 2，结果导致状态被静默覆盖；或在触发器里调用 INSERT INTO status_log，但事务失败时日志已写入，主表却没更新，数据不一致。
- 触发器无法读取应用层传入的
operator_id或reason，只能靠USER()或CURRENT_USER()，但这两个函数返回的是数据库连接用户，不是业务系统里的操作人 - 状态合法性判断（如“只允许从 1→2，不允许 0→2”）硬编码在触发器里，改一次要
ALTER TRIGGER，线上风险高 - MySQL 5.7 及更早版本不支持触发器中调用存储过程修改同一张表（会报
ERROR 1442），而状态流转往往需要先查再更新
为什么 WHERE status = ? 是比触发器更稳的更新方式
真正防并发、保顺序的关键，不是让数据库“自动推”，而是让应用层**显式声明意图**：这次更新只应在当前状态符合预期时才生效。
例如订单从「待审核」（1）变为「已通过」（2），正确写法是：
UPDATE orders SET status = 2, approved_at = NOW(), approved_by = 1001 WHERE id = 123 AND status = 1;
执行后必须检查 ROW_COUNT() 返回值：
- 返回
1：更新成功，状态流转完成 - 返回
0：说明当前status已不是 1（可能已被其他请求改为 2 或 3），业务应拒绝本次操作并提示“状态已变更”
这个模式天然规避了触发器的盲区：它不依赖数据库“猜”流程，而是由应用控制流转时机，并靠原子 WHERE 条件兜底防覆盖。
历史记录必须独立建表，且和主表更新同事务
单靠触发器往日志表写记录，无法保证与主表更新的原子性。MySQL 不支持跨语句的“回滚触发器写入”，一旦主表 UPDATE 失败而触发器已 INSERT 日志，就会留下脏数据。
正确做法是：在应用层开启事务，先 INSERT INTO order_status_log，再 UPDATE orders，两者都在同一个 BEGIN...COMMIT 内。
日志表结构推荐精简（避免外键、不用索引爆炸）：
CREATE TABLE order_status_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, from_status TINYINT, to_status TINYINT NOT NULL, operator_id BIGINT, reason VARCHAR(255), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_order_id (order_id), INDEX idx_created_at (created_at) );
-
from_status允许为 NULL（首次插入时），方便兼容初始状态 - 不加外键约束
FOREIGN KEY (order_id) REFERENCES orders(id)，避免级联删除拖垮主流程 - 索引只建最常用查询路径：
order_id查某订单全历史，created_at做归档或监控
MySQL 8.0+ 的 CHECK 约束能补触发器的短板，但仅限校验范围
如果你真想在数据库层加固状态合法性，CHECK CONSTRAINT 比触发器更轻量、更安全。它只校验单行数据，不涉及多表、不隐式提交，也不会引发递归问题。
例如限制订单只能按 0→1→2→3 或 0→3 跳转：
ALTER TABLE orders ADD CONSTRAINT chk_status_transition CHECK ( (status = 0) OR (status = 1 AND old_status = 0) OR (status = 2 AND old_status = 1) OR (status = 3 AND old_status IN (0, 1)) );
注意两点：
-
old_status需是表中真实字段（如prev_status），不能靠触发器临时算出——这意味着你得在 UPDATE 时显式赋值：SET status = 2, prev_status = 1 - CHECK 不校验 INSERT，所以首次插入
status = 0总是允许的；它只管“更新后的值是否合法”，不管“谁更新、为什么更新”
真正复杂的流转规则（比如“审批人必须是该部门直属上级”“驳回需填原因且长度≥5”）仍得放在应用层，数据库只做最后一道数值校验。别把状态机塞进 SQL。
