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