在设计数据库表结构时，经常会遇到某个字段的取值范围是固定的几种情况，比如订单状态只能是待支付、已支付、已发货、已完成，用户角色只能是管理员、编辑、普通用户。直接用字符串字段存储这类数据虽然可行，但无法在数据库层面强制约束取值，容易出现脏数据。CREATE TYPE提供的枚举类型正好解决这个问题，它允许我们自定义一组命名的常量值，字段类型声明为该枚举后，任何不在枚举范围内的值都会被数据库直接拒绝。
CREATE TYPE的基本语法与使用示例
CREATE TYPE创建枚举类型的语法非常简洁，关键字AS ENUM后面跟一个字符串常量列表即可。以PostgreSQL为例，基本形式如下：
CREATE TYPE order_status AS ENUM (
'pending', -- 待支付
'paid', -- 已支付
'shipped', -- 已发货
'completed' -- 已完成
);执行成功后，数据库系统表中就多了一个名为order_status的自定义类型。此时可以在建表语句中直接引用它，就像使用integer或varchar这些内置类型一样自然：
CREATE TABLE orders (
id BIGSERIAL PRIMARY KEY,
order_no VARCHAR(32) NOT NULL,
status order_status NOT NULL DEFAULT 'pending',
created_at TIMESTAMP DEFAULT NOW()
);插入数据时，状态字段必须使用枚举中定义过的值，否则会报错。比如执行INSERT INTO orders (order_no, status) VALUES ('A1001', 'paid')可以成功，但如果写成'payed'这种拼写错误，数据库会抛出invalid input value for enum的异常，从入口上就拦截了脏数据，这是普通字符串字段做不到的。
查询枚举字段也很方便，可以直接按值过滤，排序时默认按照枚举定义时的顺序而不是字母顺序，这一点和CHECK约束配合varchar的方式有明显差异。如果想显式控制排序，也可以对枚举值做类型转换后按文本排序。
枚举类型的修改与管理操作
很多初学者以为枚举类型创建后就不能改了，其实不然。PostgreSQL从10.0版本开始支持ALTER TYPE ... ADD VALUE语句，可以往已有的枚举类型中追加新值：
-- 追加一个取消状态 ALTER TYPE order_status ADD VALUE 'cancelled'; -- 如果希望新值排在已有值前面，可以指定位置 ALTER TYPE order_status ADD VALUE IF NOT EXISTS 'refunding' BEFORE 'pending';
需要注意的是，追加新值的事务有一定限制，在较老版本中，ALTER TYPE ADD VALUE不能放在有其他语句使用该枚举类型的事务块中执行，遇到报错时可以把这条语句单独提交。另外，IF NOT EXISTS选项可以避免重复添加时抛异常，在迁移脚本中建议始终带上。
不过枚举类型的管理也有短板：重命名某个值虽然可以用ALTER TYPE ... RENAME VALUE完成，但直接删除某个已有的枚举值在PostgreSQL中并不被支持。如果确实要删值，通常的做法是新建一个枚举类型，把表的字段类型改过去，再删掉旧类型。整个流程可以概括为：创建新类型、用ALTER TABLE ... ALTER COLUMN ... TYPE ... USING转换字段、删除旧类型。如果枚举值未来可能频繁变动，就要慎重考虑是否适合用枚举。
查看当前数据库中有哪些枚举类型，可以查询系统视图，比较常用的一条SQL是：
SELECT n.nspname AS schema_name,
t.typname AS type_name,
array_agg(e.enumlabel ORDER BY e.enumsortorder) AS enum_values
FROM pg_type t
JOIN pg_enum e ON t.oid = e.enumtypid
JOIN pg_namespace n ON t.oid = n.nspextnamespace OR n.oid = t.typnamespace
GROUP BY n.nspname, t.typname;这条查询会把每个枚举类型的所有取值按定义顺序列出来，在排查环境差异、核对迁移是否执行到位时非常实用。
枚举类型与其他方案的对比选型
除了枚举，限制字段取值还有两种常见做法：varchar加CHECK约束，以及smallint加映射表。三种方案各有适用场景，下面从约束强度、存储、可维护性几个维度做比较。
使用varchar加CHECK约束的方式，优点是修改取值范围非常灵活，直接ALTER TABLE ... DROP CONSTRAINT再加新约束即可，还能删除值。缺点是约束和字段耦合，多个表共用同一组值时要重复定义，而且排序只能按字母顺序。枚举类型则相反，它是独立的数据库对象，多处引用都指向同一份定义，排序天然按业务含义来，存储上占4字节，通常比varchar更紧凑。smallint加映射表的方案扩展性最强，还能给每个状态附加额外属性，比如颜色、描述文案，但查询需要JOIN，开发成本略高。
一般来说，取值稳定、数量不多、被多个表共享的状态字段最适合用枚举类型，比如订单状态、审核状态、日志级别。如果业务还在快速演进，取值可能频繁增删，或者每个值需要携带附加信息，那用映射表会更省心。CHECK约束则适合只在单表出现、且不太可能变动的简单约束。
最后提醒两个常见的坑：一是枚举值的大小写敏感，插入时Pending和pending是两个不同的值，字段定义时建议统一小写并在应用层保持一致；二是不同数据库对枚举的支持差异较大，MySQL用ENUM('a','b')内联在建表语句里，SQL Server则没有原生枚举，需要用CREATE TYPE配合约束模拟，迁移数据库时这些差异要提前评估。
CREATE TYPE枚举类型PostgreSQL修改时间：2026-09-08 12:40:50