postgresql的check约束支持not valid选项，允许添加约束时不校验现有数据，仅对新插入或更新的数据生效，状态为“未验证”；后续可通过validate constraint渐进校验全表。
PostgreSQL 中的 CHECK 约束支持 NOT VALID 选项，它允许你添加约束而不立即校验现有数据，这对线上表的结构演进非常关键。
NOT VALID 的核心作用
普通 ADD CONSTRAINT 会扫描全表验证所有行是否满足条件，若存在违规数据则操作失败。而加上 NOT VALID 后，约束仅对后续新插入或更新的数据生效，旧数据暂不检查，约束状态为“未验证”（pg_constraint.convalidated = false）。
这让你能安全地在已有大量数据的生产表上引入业务规则，避免锁表、长时间阻塞或因历史脏数据导致加约束失败。
渐进式添加 CHECK 约束的典型步骤
以给用户表 users 添加“邮箱必须含 @ 符号”的约束为例：
-
第一步：添加 NOT VALID 约束
ALTER TABLE users ADD CONSTRAINT chk_email_at CHECK (email ~ '@') NOT VALID; -
第二步：修复或标记违规旧数据（可选但推荐）
查询问题数据：SELECT id, email FROM users WHERE email !~ '@';
根据业务决定是清洗、归档还是临时忽略（如设置为 NULL 或占位符）。 -
第三步：验证并启用约束
运行ALTER TABLE users VALIDATE CONSTRAINT chk_email_at;
此时 PostgreSQL 会扫描全表校验——仅检查尚未满足约束的行。若全部通过，约束状态变为VALID；否则报错并中止。
使用中的关键注意事项
NOT VALID 约束虽不校验历史数据，但仍参与查询优化器的推理（例如谓词下推），因此需确保语义合理。另外：
- 该特性仅 PostgreSQL 支持，MySQL、SQL Server 等不提供等价语法；
-
VALIDATE CONSTRAINT是事务性操作，执行期间会对表加SHARE UPDATE EXCLUSIVE锁，影响 DDL 但一般不影响 DML； - 可通过
\d+ 表名或查pg_constraint视图确认约束是否已验证（convalidated字段）； - 若只想让约束“存在但永不验证”，可长期保持
NOT VALID状态，适用于灰度验证或监控阶段。
与触发器或应用层校验的对比优势
相比用触发器模拟 CHECK 或依赖应用代码校验，NOT VALID + VALIDATE 方案更轻量、一致性强且无需修改业务逻辑：
- 触发器需额外维护、可能被绕过、性能开销更高；
- 应用层校验无法防止直连数据库的误操作（如运维脚本、其他服务接入）；
- 而 CHECK 约束由数据库强制执行，天然具备 ACID 保障和跨客户端一致性。
