PostgreSQL 15.2中Check约束与触发器的核心差异及性能疑问

核心差异 #

1. 触发时机与适用场景 #

• Check约束：仅在当前表的INSERT/UPDATE行级操作时触发，且处于数据写入前的校验阶段。它无法响应DELETE、TRUNCATE操作，也不能主动触发，完全绑定到当前行的字段变更逻辑。
• 触发器：支持自定义触发时机（BEFORE/AFTER/INSTEAD OF），触发事件覆盖INSERT/UPDATE/DELETE/TRUNCATE，还可选择行级（FOR EACH ROW）或语句级（FOR EACH STATEMENT）执行。比如AFTER DELETE触发器可在删除行后完成清理关联数据的逻辑，这是Check约束无法实现的。

2. 功能边界限制 #

• Check约束：即使使用自定义PL/pgSQL函数，也不允许产生副作用——比如修改其他表数据、执行事务控制（COMMIT/ROLLBACK）都会直接报错。此外，INSERT场景下无法访问OLD值，逻辑必须围绕当前行的字段合法性展开。
• 触发器：无上述限制，函数内可自由读写任意表、控制事务流程，行级触发器能同时获取NEW和OLD值（UPDATE/DELETE场景），甚至通过INSTEAD OF触发器替代原操作的默认逻辑（比如将INSERT重定向到其他表）。

3. 错误处理逻辑 #

• Check约束：校验失败时直接终止当前操作，抛出约束违反错误，没有自定义处理的空间——逻辑只能是“符合规则则通过，否则报错”。
• 触发器：可在函数内实现自定义错误处理，比如捕获异常后记录日志、回滚部分操作，甚至在BEFORE触发器中修改NEW值修正数据（如自动补全默认值），而非直接终止操作。

选型是否取决于函数体？ #

不完全是，核心是业务逻辑的需求匹配：

• 若仅需当前行的字段合法性校验（如年龄>0、邮箱格式合规），优先选Check约束——它是数据库的声明式约束，语义清晰，PostgreSQL还会对其做查询优化（比如利用约束条件过滤数据）。
• 若逻辑涉及跨表操作、响应DELETE/TRUNCATE、修改数据而非仅校验、或需要复杂错误处理，则只能选择触发器。
  函数体复杂度是参考因素，但本质是需求是否在两者的能力边界内。

性能影响对比 #

• Check约束：性能开销极低，几乎可忽略。因为它在数据校验阶段执行，PostgreSQL会对无副作用的自定义函数做内联优化，不会产生额外事务日志开销。
• 触发器：性能开销高于Check约束，尤其是AFTER行级触发器——批量操作（如一次插入1000行）时，行级触发器会逐行执行函数，累计开销明显。若触发器涉及跨表修改，还会增加事务锁竞争和日志量。不过BEFORE触发器仅修改NEW值时，性能接近Check约束，但仍因触发器的执行流程复杂度略高。

内容的提问来源于stack exchange，提问作者Morteza Seydi