为了保证业务数据的准确性与一致性，PostgreSQL提供了一套从简单到复杂的约束机制。约束本质上是数据库对写入数据设置的“安检关卡”，每一行数据在插入或更新时都必须通过规则验证。与在应用层写大量if判断相比，数据库约束更贴近数据本身，不仅能在任何客户端写入时统一生效，还能让表结构具备自解释性。理解这些约束的精髓，是设计可靠表结构的第一步。
五大基础约束的使用场景与注意事项
PostgreSQL中的基础约束包含了我们最常使用的五种规则：非空约束、唯一约束、主键约束、外键约束和检查约束。这五种约束覆盖了绝大多数数据校验需求，但很多开发者对它们的细节并不熟悉，容易在不经意间留下隐患。下面逐个展开。
非空约束NOT NULL是最简单的约束，它强制某一列不允许写入NULL值。但要注意NULL并不等于空字符串，例如用户表中的手机号字段，如果规定必须填写，则应该设置为NOT NULL，同时还需要根据业务需要决定是否允许空字符串''。在PostgreSQL中，空字符串是合法的非NULL值，如果业务上不允许空字符串，还需要额外增加CHECK约束来过滤。此外，在某些场景下NULL反而表示“未知”或“不适用”，比如员工离职日期，未离职的员工该字段应为NULL，因此不是所有字段都适合加NOT NULL。
唯一约束UNIQUE保证一列或一组列中的数据不重复。它允许NULL值，而且PostgreSQL默认不会将两个NULL视为重复，这一点和Oracle不同。如果需要完全禁止重复的“未知值”，可以通过唯一索引配合COALESCE表达式来实现。唯一约束在业务中常用于账号、身份证号等自然键。此外，唯一约束会自动创建唯一索引，这会给查询带来额外性能收益，但也会增加写操作的索引维护成本，高并发写入时需要注意。
主键约束PRIMARY KEY等价于UNIQUE加上NOT NULL，但它还有一个隐藏特性：一个表只能有一个主键，而多个唯一约束则可以存在多个。主键通常使用自增整数或UUID，但在选择主键类型时，要综合考虑存储空间、插入性能和索引碎片问题。自增整数紧凑且性能好，UUID则更适合分布式系统。另外，使用复合主键时要格外谨慎，复合主键如果列过多，不仅会造成外键引用麻烦，还会降低索引效率，很多情况下引入一个单列代理主键是更清晰的选择。
外键约束FOREIGN KEY是关系型数据库中最重要的完整性机制，它保证子表中的引用值一定在主表中存在。外键的配置不只是一两句REFERENCES，还包括对删除和更新行为的处理。默认情况下，如果主表某行被子表引用，则无法直接删除该行，除非使用ON DELETE CASCADE或ON DELETE SET NULL。选择哪种级联策略需要谨慎：例如删除用户时如果不希望保留其订单数据，可以选择CASCADE；如果希望订单中保留用户ID快照，则改成SET NULL并让订单表该列可空。
检查约束CHECK是定义业务规则的利器，它允许你指定一个返回布尔值的表达式，只要该表达式为TRUE或NULL，数据就允许写入。例如限制年龄在0到120之间，可以用CHECK (age >= 0 AND age <= 120)。注意，表达式结果为NULL时也会通过，因此如果希望字段不能为NULL，还需要叠加NOT NULL。CHECK约束可以引用同一行中的多个列，比如开始日期必须早于结束日期的判断，这种跨列校验在很多表设计中被遗忘，导致应用层不得不反复做防御性检查。
约束的命名、添加与动态管理
创建表时，约束既可以内联写在列定义里，也可以作为表级约束单独声明。内联写法简洁，但无法为约束指定有意义的名称。更好的做法是使用表级约束并明确命名，例如：
CREATE TABLE user_profile (
id BIGSERIAL PRIMARY KEY,
email VARCHAR(255),
age INT,
status VARCHAR(20),
CONSTRAINT user_email_unique UNIQUE (email),
CONSTRAINT user_age_check CHECK (age >= 0 AND age <= 120),
CONSTRAINT user_status_valid CHECK (status IN ('active', 'disabled'))
);
约束名称在数据库内部会与错误信息一起返回。如果约束未命名，PostgreSQL会自动生成带表名和列名的组合，但可读性较差。当应用在捕获数据库异常时，往往需要解析错误消息中的约束名，此时显式命名能极大提升排查效率。除了可读性，命名约束还直接关系到后续的约束修改操作——比如你要删除某个特定约束，必须知道它的名字。
约束并非在表创建后就不能改变。你可以使用ALTER TABLE语句动态添加或删除约束。添加约束时，数据库会扫描现有数据，如果已有数据违反约束，则操作失败。通过将约束设置为NOT VALID，可以跳过对旧数据的检查，之后再通过VALIDATE CONSTRAINT命令逐步校验。这种方法非常适合在数据量巨大的生产环境中逐步收缩约束范围，避免一次性全表扫描导致锁表时间过长。
约束管理还有一个常见误区：很多人认为删除约束会连带删除相关索引。对于唯一约束和主键约束，PostgreSQL确实会删除其自动创建的索引，但普通CHECK约束和外部键约束不会创建额外索引，它们依赖的是字段本身的索引。所以在删除唯一约束时，如果业务上仍需要该字段的索引加速查询，重新创建普通索引即可。同时还要注意，外键约束的关联字段最好在子表上建立索引，否则在删除主表数据或修改关联键时，子表的扫描效率会很低。
利用触发器和域进行自定义数据校验
基础约束虽然强大，但面对复杂业务规则时仍显不足。比如需要校验“一个用户在一个项目中只能处于一种角色”，这种涉及多行、跨表甚至需要子查询的规则，用简单的CHECK约束很难表达。此时触发器便成为首选方案。触发器在数据写入前后触发，可以读取新旧值，并执行任意的PL/pgSQL逻辑。例如在插入订单前校验商品库存是否充足，或者在更新用户时自动更新修改时间字段。触发器也可以用于实现软删除的级联逻辑，远比外键的级联行为更灵活。
使用触发器需要两个步骤：先写一个返回trigger类型的函数，再为表创建触发器。以下示例展示了如何使用触发器阻止关闭状态下的用户产生新订单：
CREATE OR REPLACE FUNCTION check_user_status()
RETURNS TRIGGER AS $$
BEGIN
IF (SELECT status FROM users WHERE id = NEW.user_id) = 'disabled' THEN
RAISE EXCEPTION 'User is disabled, cannot create order';
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER trg_check_user_status
BEFORE INSERT ON orders
FOR EACH ROW
EXECUTE FUNCTION check_user_status();
触发器虽然灵活，但过度使用会让业务逻辑散落在数据库内部，造成应用层难以理解和调试。因此建议只在数据一致性要求极高、或无法用约束表达的场景中使用。另一种更数学化的校验工具是域（DOMAIN）。域本质上是一种自定义数据类型，它允许你封装一个基础类型，并附加CHECK约束。例如为“邮箱地址”创建一个域，之后在任意表中使用这个域作为列类型，就能自动继承邮箱格式校验，避免重复编写相同的CHECK规则。域的复用价值非常高，适合在多个表中统一维护某一类字段的规则。
域也可以附加默认值和NOT NULL属性。当需要对某类字段的规则进行统一修改时，只需修改域定义，所有引用该域的表都会自动生效。不过要注意，域不接受表级上下文，因此域中的CHECK表达式不能引用其他列。如果校验逻辑需要同时依赖多个列，仍然只能使用表级CHECK约束或触发器。在实际设计中，域的适用场景包括：状态码、性别、百分比、ISBN号码等具有明确取值规则的字段。
约束设计的最佳实践与常见误区
设计约束时最常见的误区是“越多越好”。过多的校验会降低写入性能，并给业务迭代带来沉重负担。比如某些枚举字段，如果业务频繁扩展取值，硬编码的CHECK约束就会成为每次变更都需要执行的DDL操作。此时，如果枚举值的变更频率较高，可以改用引用枚举字典表的外键方式，而不是CHECK约束。反过来，“完全没有约束”则是更大的灾难。很多快速原型项目为了省事直接留空所有约束，等到数据污染后再用脚本清理，代价远大于建表时多写几行约束声明。
另一个容易被忽略的问题是约束之间的相互作用。当NOT NULL、UNIQUE和CHECK同时出现在一列上时，执行顺序取决于具体的操作。PostgreSQL在写入数据时，会先检查NOT NULL约束，再检查CHECK约束，最后检查唯一约束。理解这个顺序有助于调试，但更重要的是能够合理划分职责：列的基本属性用约束，跨行跨表的一致性用外键或触发器，格式规范用域或CHECK。
在性能方面，约束的存在会让写入路径变长，特别是外键约束，每一次插入或更新子表数据都需要查找主表。为了降低开销，可以在外键对应的子表列上建立索引。此外，对于很少发生删除和更新的大批量数据装载场景，可以暂时删除外键约束，加载完成后再重建，不过这样做需要确保加载过程中外部应用不会破坏引用关系，否则重建约束时会因为数据不合法而失败。
最后，约束的设计文档也不可忽视。在表结构定义文件中，通过清晰的注释说明每个约束的业务含义，能够让后来的维护者快速理解“为什么这里要这么限制”。一个训练有素的团队，应该把约束设计当作数据模型设计的一部分，而不是事后的补丁。当你在PostgreSQL中规划表时，请记得：约束不是开发的对立面，而是数据质量的第一道防线。
PostgreSQL数据校验完整性约束修改时间：2026-08-22 16:52:06