推荐用 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 字段无法追溯“谁、何时、为什么改”，必须分离「当前态」和「流转过程」。建独立日志表是底线。
