推荐用 TINYINT 存储订单状态码（如 0=待支付、1=已支付等），而非 ENUM 或 VARCHAR，以支持灵活扩展、高效索引与范围查询；状态变更须通过带条件的原子 UPDATE 实现，并校验影响行数；需配套状态日志表记录每次变更详情，且状态字段应结合高频查询条件建立复合索引。
订单状态流转的核心是用状态机思维设计字段和逻辑，避免硬编码判断、防止状态非法跳转、兼顾可扩展性和查询效率。
状态字段设计：用枚举还是整型？
推荐使用 TINYINT 存储状态码（如 0=待支付、1=已支付、2=已发货、3=已完成、-1=已取消），而非 ENUM 或 VARCHAR。原因很实际：后期新增状态不用改表结构（ALTER TABLE 添加注释即可），索引效率高，程序里用常量映射语义，也方便排序和范围查询（比如查“所有未完成订单”：WHERE status IN (0,1,2)）。
配套建议：
- 在代码中定义清晰的状态常量类（如 Java 的
OrderStatus枚举），数据库只存数字，避免双写语义 - 为
status字段加注释，说明每个值含义，例如：COMMENT '0:待支付,1:已支付,2:已发货,3:已完成,-1:已取消' - 不单独建状态字典表——除非状态有复杂属性（如对应操作人、超时规则），否则小而固定的状态反而增加 JOIN 和维护成本
状态变更：必须走原子更新 + 条件校验
禁止先 SELECT 再 UPDATE。正确做法是用一条带条件的 UPDATE 语句，确保只有当前状态符合条件才能变更，防止并发或异常导致状态错乱。例如支付成功后将“待支付”转为“已支付”：
UPDATE orders SET status = 1, paid_at = NOW() WHERE id = 123 AND status = 0;
执行后检查 影响行数是否为 1。如果为 0，说明状态已被其他流程修改（比如用户重复点击支付），应抛出业务异常，而不是静默忽略。
关键点：
- 每次状态变更都明确写出“从哪来、到哪去”，不依赖当前值做分支判断
- 涉及多表更新（如同时更新订单主表和记录日志表）时，务必包裹在事务中
- 对敏感操作（如取消订单）可额外校验业务条件，例如：
AND created_at > DATE_SUB(NOW(), INTERVAL 30 MINUTE)
状态历史留痕：用独立日志表记录每一次变更
不要只靠订单主表的 status 字段追溯过程。建一张 order_status_log 表：
id, order_id, from_status, to_status, operator_type, operator_id, remark, created_at
每次状态变更时，无论成功与否，都插入一条日志（成功则 commit，失败则 rollback 整个事务）。这样能快速定位问题：某订单为什么没发货？查日志就知道卡在哪个环节、谁操作的、有没有备注。
实用技巧：
-
operator_type区分是系统自动（如支付回调）、用户触发（APP 点击）、还是人工后台（客服强制改单） - 把关键业务参数（如支付流水号、物流单号）记在
remark字段，JSON 格式存储更灵活 - 给
(order_id, created_at)加联合索引，支持按订单查时间线
查询与统计：状态字段要支持高效过滤
订单列表页常需按状态筛选（如“查看我所有待发货订单”），状态字段必须加索引。但注意：不要只为 status 单独建索引，而是结合高频查询条件建复合索引。例如用户中心查个人订单，常用 user_id + status，那就建：
INDEX idx_user_status (user_id, status)
再比如后台需要查“昨天所有已取消订单”，就可能需要 INDEX idx_status_created (status, created_at)。
顺便提醒：
- 避免在 status 字段上用函数或表达式（如
WHERE status != 3没问题，但WHERE ABS(status) = 1会失效索引） - 状态值尽量紧凑、连续，减少范围扫描开销；预留空位（如跳过 4、5）方便未来插入中间状态（如“已揽收”）
状态设计不是定好字段就完事，关键是每次变更都受控、可溯、可查。把规则落在 SQL 和事务里，比靠代码逻辑兜底更可靠。
