推荐用 TINYINT 而非 ENUM 存储状态字段，因其更稳妥：避免 DDL 锁表、减少拼写与字符集风险；配合注释、常量类及 CHECK 约束（MySQL 8.0.16+）控制合法流转，并建独立日志表记录变更全过程。
状态字段用 TINYINT 还是 ENUM？
直接用 TINYINT 更稳妥。虽然 ENUM 看似语义清晰，但增删状态时要 ALTER TABLE，线上 DDL 锁表风险高；且 ORM 或应用层做状态校验时，ENUM 的字符串值容易拼错、大小写敏感、迁移时字符集还可能出问题。TINYINT 配合注释和常量定义，既轻量又可控。
- 推荐定义：0 →
draft，1 →pending_review，2 →approved，3 →rejected，-1 →archived - 建表时加注释：
status TINYINT NOT NULL DEFAULT 0 COMMENT '0:draft,1:pending_review,2:approved,3:rejected,-1:archived' - 应用层统一用常量类或枚举类管理映射，避免硬编码数字
如何防止非法状态跳转？
靠应用层校验不保险，必须在数据库层加固。用 CHECK CONSTRAINT（MySQL 8.0.16+）限制合法流转路径，比触发器更轻量、更易读。
ALTER TABLE orders ADD CONSTRAINT chk_status_transition CHECK ( (status = 0 AND old_status IN (NULL)) OR (status = 1 AND old_status = 0) OR (status = 2 AND old_status IN (1, 3)) OR (status = 3 AND old_status = 1) OR (status = -1 AND old_status IN (0, 2)) );
注意：old_status 需为同一行的前一状态（通常需配合更新逻辑记录历史），若要严格审计，建议额外建 order_status_logs 表，主表只存当前 status，流转由业务代码控制并写日志。
- 禁止跨步跳转：比如从
draft(0)直接到approved(2)，必须经pending_review(1) -
CHECK不校验初始插入（old_status为空），所以首次插入默认允许0，后续更新才受约束 - 低版本 MySQL 可用触发器模拟，但性能开销大，且难以覆盖所有客户端入口
状态变更需要留痕？别只靠 UPDATE
单靠更新主表 status 字段无法追溯“谁、何时、为什么改”，必须分离「当前态」和「流转过程」。建独立日志表是底线。
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) );
- 每次状态变更，先 INSERT 日志，再 UPDATE 主表 —— 两者应放在同一事务中
-
reason字段必填（哪怕只是 “auto-approved by rule#123”），避免后期排查时只剩“不知道谁点的提交” - 不要用 JSON 存多状态字段进一个字段，查起来慢、索引失效、没法按流转阶段统计
查询某类待处理订单时，WHERE 条件写法有坑
常见错误是写成 WHERE status IN (1, 3) 以为能查出所有“待审核或已拒绝可重提”的单子，但实际业务中，“待处理”往往隐含时间、权限、上下文等条件，纯状态过滤会漏或泛。
- 例如审核列表应加时效：
WHERE status = 1 AND updated_at - 用户端查看自己的单子，必须加
AND user_id = ?，否则可能越权看到他人数据 - 复合状态判断慎用
OR：如status = 1 OR (status = 2 AND approved_by IS NULL)，这种容易让优化器放弃索引，建议拆成UNION或改用函数索引（MySQL 8.0.13+）
状态流转本身不复杂，真正难的是把「人怎么想」翻译成「数据库怎么记」——哪个字段该冗余，哪条路径必须阻断，哪些操作必须落痕，这些细节一旦上线就很难回退。
