订单状态流转不能只靠应用层UPDATE，因会漏掉状态跳变、重复变更及并发一致性校验；必须用存储过程封装校验与更新，在数据库层面强制执行迁移规则，如SQL Server用IF EXISTS查当前状态是否允许目标状态，PostgreSQL用UPDATE...RETURNING配合WHERE状态校验，MySQL用ROW_COUNT()判断更新是否生效并SIGNAL报错。
订单状态流转为什么不能只靠应用层更新
直接在代码里用 UPDATE orders SET status = 'shipped' 看似简单，但会漏掉关键约束：状态不能跳变（比如从 'created' 直接到 'delivered'），也不能重复变更（同一订单多次触发发货逻辑），更难保证并发下的一致性。存储过程把校验和更新封装在一起，数据库层面强制执行规则。
SQL Server 存储过程中如何校验合法状态迁移
核心是用 CASE 或 IF EXISTS 查当前状态是否允许目标状态。别依赖应用传来的“上一个状态”，必须查表实时读取：
IF NOT EXISTS (
SELECT 1 FROM orders
WHERE order_id = @order_id
AND status IN ('confirmed', 'paid') -- 只有这两个状态才允许转为 shipped
)-
@order_id和@new_status必须作为输入参数，不要硬编码状态值 - 避免用
SELECT status INTO @old_status再判断——多一次 IO，且中间可能被其他事务修改 - 把合法迁移路径写成显式列表（如
('created' → 'confirmed'),('confirmed' → 'shipped')），比用数字编码更易维护
PostgreSQL 中用 RETURNING 避免二次查询
PostgreSQL 的 UPDATE ... RETURNING 能在更新同时返回结果，省去后续 SELECT。但要注意：如果更新没匹配到行（比如订单不存在或状态不满足），RETURNING 不返回任何数据，应用层必须处理空结果：
UPDATE orders SET status = 'shipped', updated_at = NOW() WHERE order_id = $1 AND status = 'confirmed' RETURNING order_id, status;
- WHERE 条件里必须包含当前状态校验，否则会绕过状态机规则
- 不要在 RETURNING 里返回敏感字段（如
payment_amount），除非业务明确需要 - 如果需要记录变更日志，建议在存储过程里另起一条
INSERT INTO order_status_log，别指望 RETURNING 能替代审计
MySQL 存储过程里怎么处理并发更新冲突
MySQL 默认隔离级别下，并发执行同一订单的状态更新可能导致“丢失更新”。解决方案不是加锁语句，而是靠 UPDATE 的影响行数判断：
UPDATE orders SET status = 'delivered' WHERE order_id = in_order_id AND status = 'shipped'; -- 关键：把旧状态作为 WHERE 条件 IF ROW_COUNT() = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid status transition'; END IF;
-
ROW_COUNT()返回实际更新的行数，为 0 说明条件不满足（可能是状态已变、订单不存在或被其他事务抢先更新） - 别用
SELECT ... FOR UPDATE—— 它会阻塞，且在高并发下单点瓶颈明显 - 应用层收到错误后应重试或提示用户“操作已被其他操作覆盖”，而不是静默失败
状态流转的复杂点不在 SQL 语法，而在迁移路径定义是否覆盖所有业务场景；最容易被忽略的是：没人检查存储过程被谁调用、有没有绕过它直连数据库更新 status 字段。
