MySQL 中的状态字段设计，核心是兼顾可读性、扩展性与查询效率，避免硬编码、魔法数字和频繁 DDL 变更。
状态字段类型选 TINYINT 而非 ENUM 或 VARCHAR
用 TINYINT(1) 存储状态码（如 0=待审核, 1=已通过, 2=已拒绝, 99=已作废），比 ENUM 更灵活——新增状态无需改表结构；比 VARCHAR 更省空间、索引效率更高、排序天然有序。配合注释或字典表，语义不丢失。
建表时加 COMMENT 说明每个值含义，例如：`status TINYINT NOT NULL DEFAULT 0 COMMENT '0-草稿,1-待审,2-通过,3-驳回,99-归档' 应用层统一定义状态常量（如 Java 的 enum / Python 的 IntEnum），确保代码与数据库一致 避免用 TINYINT(1) 存布尔值（如 0/1 表示启用禁用）——语义单薄，后期难扩展配套维护一张 状态字典表（可选但推荐）
对中大型系统，建议单独建
sys_dict_status表管理所有业务状态，含字段：
type（如 'order_status', 'user_status'）、
code（数值）、
name（中文名）、
sort、
is_enabled。好处是： 前端下拉、后台列表可直接查字典渲染，无需硬编码文案 运营可自助配置新状态（如临时增加“灰度中”），开发零介入 支持多语言 name 字段（扩展字段或关联 i18n 表） 通过
is_enabled控制状态是否仍可被新数据选用，旧数据保持兼容
状态变更走 事务 + 状态机校验，不裸 update
禁止直接
UPDATE table SET status = 2 WHERE id = 123。应在应用层或存储过程中实现状态流转约束： 定义合法转移路径，如：草稿 → 待审 → 通过/驳回 → 归档，不允许从“驳回”直接跳到“通过” 更新前查当前状态，校验是否允许本次变更（可用 CASE WHEN 或字典表预置 transition 规则） 关键操作（如支付成功触发订单状态变“已支付”）必须包裹在事务中，关联更新时间、操作人等审计字段 留痕：记录状态变更日志表（含 old_status, new_status, operator, remark, created_at）
查询优化：为状态字段加 复合索引，慎用函数
状态字段单独索引效果有限（低选择性），应结合高频查询条件建复合索引：
例如订单表常查“未发货的待支付订单”，建索引：INDEX idx_status_paytime (status, pay_time)避免在 WHERE 中对状态字段用函数，如
WHERE CAST(status AS CHAR) = '1'会失效索引 统计类查询（如各状态数量）可考虑用物化视图（MySQL 8.0+）或定时汇总表，减少 COUNT() 全扫
