状态字段应使用整型枚举（如TINYINT）替代字符串，预留间隔编号并设默认非空约束，拆分多维语义为独立字段，必要时引入状态机表记录流转。
状态字段看似简单，但设计不当容易引发逻辑混乱、查询低效、扩展困难等问题。关键在于兼顾可读性、可维护性与数据库性能。
用整型枚举代替字符串存储状态值
避免直接用 'pending'、'approved' 等字符串存入状态字段。字符串占用空间大、索引效率低、拼写易出错，且不便于程序比对。推荐使用 tinyint 或 smallint 类型，配合注释或字典表明确含义。
- 例如：status TINYINT NOT NULL COMMENT '0-待提交,1-审核中,2-已通过,3-已拒绝,4-已撤销'
- 应用层通过常量映射（如 Status.PENDING = 0）管理语义，避免硬编码字符串
- 若状态种类较多或需频繁变更，可单独建 sys_status 字典表，主表只存 status_id
预留“中间态”和“异常态”位置
业务发展常带来新状态，初期设计要留余地。不要从 0 或 1 连续排满，建议按 10 倍间隔预留，方便后续插入。
- 例如：0-初始, 10-待支付, 20-支付中, 30-已支付, 40-已发货, 50-已完成, 99-已作废
- 为异常流程预留专用值（如 -1-系统错误, 98-人工干预中），避免用“已支付”去覆盖异常场景
- 上线前和迭代评审时，同步更新数据库注释与代码常量，确保两端一致
避免用状态字段承载多重语义
一个字段只表达一种维度的状态。例如“订单状态”不应同时隐含“是否可退款”“是否开票”“是否计入业绩”，这些应拆分为独立布尔字段或关联状态机。
- 反例：用 status=5 表示“已完成且已开票且不可退款”，导致状态膨胀、逻辑耦合
- 正解：保留 order_status，另设 is_invoiced TINYINT(1), can_refund TINYINT(1) 等清晰字段
- 复杂状态流转建议引入状态机表（如 order_status_log），记录每次变更的时间、操作人、原因
合理使用默认值与非空约束
状态字段通常不应为 NULL，且必须有明确初始值。NULL 容易引发 WHERE 条件遗漏、聚合统计偏差等问题。
- 建表时显式指定 DEFAULT，如 status TINYINT NOT NULL DEFAULT 0
- INSERT 时不显式赋值也能自动填充，降低应用层出错概率
- 若某些状态仅由后台触发（如“已风控拦截”），可在 INSERT 时设为默认态，再由服务异步更新
