状态字段用 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+）
状态流转本身不复杂，真正难的是把「人怎么想」翻译成「数据库怎么记」——哪个字段该冗余，哪条路径必须阻断，哪些操作必须落痕，这些细节一旦上线就很难回退。
