SQL CHECK 约束的表级 vs 列级声明与触发器替代对比

列级check约束仅支持单字段校验，跨字段逻辑必须用表级check；触发器可实现复杂校验但无优化器支持；mysql与postgresql在函数支持、延迟约束等方面存在关键差异。

列级 CHECK 约束只能引用单个字段

列级 CHECK 是写在字段定义后面的，比如 age int CHECK (age >= 0)。它天然受限于语法：括号里只能出现当前字段名，不能跨字段引用。一旦你想表达“入职日期不能晚于离职日期”，这种跨字段逻辑，在列级里直接写会报错——PostgreSQL 报 Error: column "leave_date" does not exist，MySQL 8.0+ 虽支持但实际仍限制为单列上下文。

实操建议：

• 纯单字段校验（如非负、范围、枚举值）优先用列级，语义清晰、建表语句紧凑
• 只要涉及两个及以上字段比较，必须升到表级 CHECK，否则语法不通过
• sqlite 对列级 CHECK 的解析较宽松，但行为不一致，别依赖

表级 CHECK 约束能跨字段但不触发 UPDATE 级联检查

表级 CHECK 写在建表语句末尾，例如 CONSTRAINT valid_dates CHECK (hire_date 。它确实能引用多列，但关键限制是：只在校验整行 INSERT 或 UPDATE 后的最终状态，不关心中间过程。这意味着如果你分两步更新：<code>UPDATE emp SET hire_date = '2025-01-01'，再 UPDATE emp SET leave_date = '2024-12-01'，第二条可能失败；但如果合并成一条 SET hire_date = ..., leave_date = ...，就只校验最终值。

常见错误现象：

• 应用层分步更新时，突然遇到 check constraint "valid_dates" is violated
• 批量导入数据时，某条记录因临时不满足约束被拒，但你没意识到是中间态问题
• MySQL 5.7 不支持表级 CHECK（被解析但忽略），升级到 8.0.16+ 才真正生效

触发器能做动态校验但绕过约束机制

当你要在 UPDATE 前查另一张表（比如“部门预算余额 > 本次薪资调整额”），或者需要抛出自定义错误信息，CHECK 束手无策，只能上触发器。但触发器不是约束替代品，它是运行时逻辑，不参与查询优化器的约束推导，也不保证 MVCC 下的严格一致性。

使用场景与风险：

• 需要访问其他表、调用函数、或基于当前时间/用户会话做判断时，触发器是唯一选择
• BEFORE INSERT OR UPDATE 触发器中用 raise EXCEPTION（PostgreSQL）或 signal SQLSTATE（MySQL）可模拟约束报错，但错误码和消息格式和原生 CHECK 不同
• 触发器里执行 select 可能引发锁等待，高并发下成为瓶颈；而 CHECK 是纯内存校验，无锁

MySQL 和 PostgreSQL 在 CHECK 处理上的关键差异

MySQL 8.0.16+ 开始真正支持 CHECK，但默认开启 check_constraint_checks，且不支持子查询；PostgreSQL 自 9.2 起就完整支持，还允许在 CHECK 中调用 immutable 函数。最易踩的坑是迁移时假设行为一致。

参数与兼容性要点：

• MySQL 中 CHECK 表达式里不能用 NOW()、CURRENT_USER() 等非确定性函数，PostgreSQL 允许但要求函数标记为 IMMUTABLE
• PostgreSQL 支持 NOT VALID 选项跳过历史数据校验，MySQL 不支持该语法
• SQL Server 的 CHECK 默认可延迟（DEFERRABLE），PostgreSQL 需显式声明，MySQL 完全不支持延迟约束

复杂点在于：CHECK 约束看起来只是加个条件，但它背后牵扯的是存储引擎如何解析、优化器是否信任、事务隔离如何交互。哪怕语法跑通了，也得看它在你的具体版本、数据分布、并发模式下是不是真起作用。