数据库状态字段应该如何设计？为什么不能只靠一个 status 随便改？

简化版

状态字段要按业务状态机设计，而不是随便放一个数字让代码任意改。好的设计要明确状态枚举、合法流转、状态变更时间、操作者、幂等与并发控制，核心规则最好由代码状态机和数据库约束共同兜住。

详细版

状态字段常见于订单、支付、审批、任务、工单等表。设计时要先定义“有哪些状态”和“哪些状态可以流向哪些状态”，再决定字段类型、命名和约束。

常见做法：

用明确的枚举值，如 pending、paid、cancelled，不要用含义不明的 1、2、3 裸值。
状态字段只表达主生命周期，不要把多个维度混进一个字段。
重要状态要配套时间字段，如 paid_at、cancelled_at、finished_at。
复杂状态变更要有状态流水表，记录 from、to、operator、reason。
更新状态时带上当前状态条件，避免并发覆盖。

比如订单从 pending 到 paid，SQL 不应直接 update order set status='paid' where id=1，而应写成 where id=1 and status='pending'，让状态流转具备并发保护。

完整版教学

一、状态字段的本质是生命周期，不是一个普通属性

很多同学会把 status 当成普通字段，觉得能存当前值就行。但状态字段真正描述的是对象处在生命周期的哪个阶段，比如订单从创建、支付、发货、完成到取消，每一步都有业务规则。

如果把状态看成普通属性，代码里就容易出现“任何地方都能改”的问题。一个订单已经 cancelled，另一个异步回调又把它改成 paid，这不是字段设计问题，而是状态机没有被建模。

设计状态字段时先画生命周期，再落字段。字段只是结果，状态机才是规则来源。

pending -> paid -> shipped -> finished
   |         |
   v         v
cancelled  refunded

记忆钩子：状态字段不是“当前值”，而是“生命周期位置”。面试回答要先讲状态机，再讲字段。

二、状态枚举要稳定、可读、可扩展

状态值可以用数字，也可以用字符串。数字节省空间，字符串可读性更强。实际工程里两者都能用，但不能让值的含义只存在于某个开发者脑子里。

如果使用数字，必须有稳定枚举定义和注释，例如 10=待支付、20=已支付、90=已取消。如果使用字符串，应保证长度和命名稳定，不要今天叫 pay_success，明天改成 paid。

状态值最好预留区间，便于后续扩展。比如订单状态用 10/20/30/40/90，中间可以插入 25=部分支付，不用大规模改历史数据。

方案	优点	风险
数字枚举	存储短、索引小、排序方便	可读性依赖代码和文档
字符串枚举	SQL 和排查时直观	长度更大，改名成本高
数据字典表	可动态展示和管理	不适合承载强业务流转规则

三、不要把多个维度压进一个 status

一个常见错误是把支付状态、发货状态、退款状态、审核状态全塞进一个 status。这样短期看字段少，长期会变成组合爆炸。

例如订单可能“已支付但未发货”“已发货但售后中”“已完成但部分退款”。如果只用一个状态，就要定义很多复合值：paid_not_shipped、shipped_refunding、finished_partial_refunded。状态越来越多，判断越来越乱。

更好的做法是区分主状态和子维度：

order_status: pending / paid / shipped / finished / cancelled
pay_status: unpaid / paid / refunded / partial_refunded
ship_status: unshipped / shipped / signed

这样每个字段负责一个维度，组合关系由业务规则管理，而不是让一个字段承担所有语义。

四、状态流转要有并发保护

状态字段最容易出问题的场景是并发更新。比如支付回调和用户取消订单同时到达，如果两条 SQL 都只按 id 更新，最后谁覆盖谁取决于执行顺序。

正确做法是在更新条件中带上当前状态，这叫条件更新，也是一种轻量状态机保护。

update orders
set status = 'paid', paid_at = now()
where id = 1001
  and status = 'pending';

如果返回影响行数为 0，说明订单已经不是 pending，这次流转应被拒绝或转入补偿逻辑。这个设计比先查再改更可靠，因为判断和更新在数据库里是一次原子操作。

五、重要状态要配套时间和操作信息

只保存当前状态，往往不足以排查问题。面试官常会追问：“用户说订单被取消了，你怎么知道是谁什么时候取消的？”这就需要配套字段或流水表。

简单业务可以在主表放关键时间：

created_at
paid_at
cancelled_at
finished_at

复杂业务应增加状态流水表：

字段	含义
`biz_id`	业务主表 ID
`from_status`	变更前状态
`to_status`	变更后状态
`operator_id`	操作人或系统来源
`reason`	变更原因
`created_at`	发生时间

如果订单一天有 100 万次状态变更，流水表会比较大，但它换来的是审计、排障和对账能力。

六、数据库约束能兜底，但不能替代业务状态机

数据库可以做一些基本约束，比如状态字段非空、默认值、枚举范围、部分数据库支持 check 约束。它们能防止明显脏数据进入表。

但数据库约束不适合表达所有复杂业务规则。比如“已发货订单只有售后系统可以进入退款中”，这种规则依赖角色、渠道、时间窗口和外部服务，放在应用层状态机更清晰。

比较稳的分层是：

应用状态机：判断能不能流转、谁能流转、需要触发什么副作用
SQL 条件更新：保证并发下只有合法旧状态能更新
数据库约束：保证字段取值、非空、唯一性等底线
状态流水：记录发生过什么

七、常见误区与追问

误区：status 字段只要能存 0、1、2 就够了。 面试重点不是字段能不能存，而是状态含义、流转规则、并发保护和审计能力是否完整。
误区：状态越细越好。 过细会导致状态爆炸，应把主生命周期和支付、物流、退款等维度拆开。
误区：只在代码里判断状态就安全。 并发下两个请求可能都读到旧状态，最终还需要 SQL 条件更新或乐观锁兜底。
追问：为什么状态更新要带旧状态条件？ 因为 where id=? and status=? 能把判断和更新合成一次原子操作，避免并发覆盖。
追问：什么时候需要状态流水表？ 只要状态变更影响钱、履约、审核、合规或排障，就应该记录流水。
追问：状态字段适合建索引吗？ 单独低基数字段选择性差，通常结合业务查询条件建联合索引，如 (status, created_at)。

八、面试中可以这样落到工程方案

回答时可以用订单举例。主表放 status、关键时间字段和版本号，状态流转由服务层状态机控制，更新时带旧状态条件，关键变更写状态流水。

比如待支付订单超时取消：

update orders
set status = 'cancelled',
    cancelled_at = now(),
    cancel_reason = 'timeout'
where id = 1001
  and status = 'pending';

如果影响行数是 1，说明取消成功，再写流水并发消息；如果是 0，说明订单已经支付或取消，不应重复处理。这个回答能同时覆盖状态机、并发、幂等和审计。

九、加强记忆

状态字段设计记四步：先画状态机，再拆维度，再做条件更新，最后补流水审计。字段本身只是一个值，真正有价值的是“哪些状态存在、哪些流转合法、并发时如何防覆盖、出问题时如何追溯”。只要围绕这四个问题回答，状态字段这类题就不会停留在“建个 status”这种浅层答案上。

简化版

详细版