不能绕过CHECK约束，但可补充其不足；触发器支持跨表引用、函数调用和动态校验，需在BEFORE触发器中显式抛异常（如MySQL用SIGNAL），且不参与查询优化，高并发下易成性能瓶颈。
触发器能绕过CHECK约束的硬性限制吗？
不能绕过，但可以补充。SQL标准中 CHECK 约束不支持子查询、跨表引用、函数调用（如 NOW()、USER()）或复杂逻辑判断；而触发器在执行 INSERT/UPDATE/DELETE 时可自由访问其他表、调用函数、抛出带描述的错误，是唯一能在 DML 层实现“动态校验”的机制。
BEFORE INSERT 触发器中如何主动拒绝非法数据？
必须在触发器内显式抛出异常，不能只靠 SELECT 或 SET 变量“静默拦截”。不同数据库语法差异大，容易漏掉关键语句导致校验失效：
- MySQL：用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'xxx'，缺SIGNAL就等于没校验 - PostgreSQL：用
RAISE EXCEPTION 'xxx'，写成RAISE NOTICE不会中断执行 - SQL Server：用
THROW 50000, 'xxx', 1或RAISERROR('xxx', 16, 1)，错误级别低于 11 不会终止事务
示例（MySQL）：
NEW
- 校验状态迁移合法性：比如
OLD.status = 'draft' AND NEW.status = 'published'才允许更新发布时间 - 防止敏感字段被意外修改：若
OLD.email != NEW.email，则要求NEW.email_verified = TRUE - 金额类字段变更需审计：当
NEW.balance != OLD.balance，强制写入balance_log表
触发器性能和递归问题怎么避坑？
触发器本质是隐式执行的额外 SQL，容易引发 N+1 查询、死锁或无限递归，尤其在涉及自身表的 UPDATE 场景下：
- 避免在触发器里做
SELECT ... FROM same_table（除非加FOR UPDATE SKIP LOCKED或明确隔离级别） - PostgreSQL 中默认允许触发器递归，若触发器内又 UPDATE 同表，需用
pg_trigger_depth() > 1检查深度 - MySQL 的
AFTER触发器无法修改NEW，但BEFORE中修改NEW字段可能意外绕过应用层意图 - 所有数据库中，触发器里调用存储过程前，先确认该过程是否也含 DML —— 多层嵌套极易失控
最常被忽略的一点：触发器不参与查询优化器的计划生成，哪怕只读校验（如 SELECT COUNT(*)），也会在每次 DML 时强制执行，线上高并发表上极易成为瓶颈。
