MySQL无内置状态码，业务中需建sys_status表统一管理状态值、名称、分类等，以提升可读性、可维护性、数据一致性与多系统协同效率。
MySQL 本身没有内置的“状态码”概念，所谓“状态码管理”其实是业务系统中常见的需求：用数字或短字符串标识某条记录所处的业务状态（如订单状态：0=待支付、1=已支付、2=已发货、3=已完成），并通过一张独立的状态码表来统一维护、约束和解释这些值。
为什么需要专门的状态码表？
直接在业务表里用硬编码数字（比如 order_status INT DEFAULT 0）虽简单，但存在明显问题：
- 可读性差：查数据库时看到 status = 2，无法直观知道代表什么
- 维护困难：状态含义变更或新增时，需同步改代码、SQL、文档，易遗漏
- 缺乏校验：数据库无法阻止插入非法值（如 status = 999）
- 多语言/多系统不一致：前端、后端、报表可能各自定义一套，导致混乱
推荐的状态码表结构设计
一张轻量、通用、可扩展的状态码表，建议包含以下字段：
- code：状态码值，主键，类型常用 TINYINT UNSIGNED（支持 0–255，足够多数业务）或 VARCHAR(10)（支持字母+数字组合，如 'PENDING'）
- name：状态名称，如 '待审核'，用于展示，非空
- desc：简要说明，如 '用户提交后未被管理员处理'，可为空
- category：状态分类，如 'order_status'、'user_status'，方便复用同一张表管理多类状态
- is_active：是否启用，类型 TINYINT(1)，便于下线旧状态而不删数据
- sort_order：排序序号，方便前端按业务流程顺序展示（如 0→1→2→3）
示例建表语句：
CREATE TABLE sys_status ( code TINYINT UNSIGNED NOT NULL PRIMARY KEY, name VARCHAR(32) NOT NULL, `desc` VARCHAR(128), category VARCHAR(32) NOT NULL, is_active TINYINT(1) DEFAULT 1, sort_order TINYINT UNSIGNED DEFAULT 0, UNIQUE KEY uk_category_code (category, code), KEY idx_category_active (category, is_active) );
业务表如何关联状态码
不建议用外键强约束（因状态码表极少删行，且外键会增加运维复杂度），推荐“逻辑外键 + 应用层校验 + 数据库 CHECK（MySQL 8.0.16+）”组合方式：
- 业务表中声明状态字段，例如：status TINYINT UNSIGNED NOT NULL DEFAULT 0
- 添加 CHECK 约束（如 MySQL ≥ 8.0.16）限制合法值范围：
CHECK (status IN (0,1,2,3)) —— 适合固定、少量状态
或更灵活地：CHECK (status BETWEEN 0 AND 255) + 应用层确保只存有效 code - 查询时通过 LEFT JOIN 关联状态表获取描述：
SELECT o.id, o.status, s.name AS status_name FROM orders o LEFT JOIN sys_status s ON o.status = s.code AND s.category = 'order_status' AND s.is_active = 1;
配套使用建议
让状态码真正“管起来”，还需配合以下实践：
- 初始化脚本固化：建库时用 SQL 脚本批量插入标准状态，避免手工录入出错
- 应用层封装枚举：Java 用 enum、Python 用 Enum 类映射 code↔name，禁止散落 magic number
- 提供管理接口：后台系统允许运营人员查看/停用状态（仅改 is_active），不可删、不可改 code
- 日志与审计：关键状态变更（如订单从 1→2）记操作日志，含前值、后值、操作人、时间
状态码表不是炫技，而是降低协作成本、提升系统健壮性的务实设计。不复杂但容易忽略。
