应优先在应用层校验，触发器仅作兜底；核心约束用DDL，跨表规则用分布式事务，遗留系统才硬控。因触发器耦合高、调试难、迁移差，且存在快照时序问题。
触发器里怎么写业务校验逻辑才不会锁表卡死
直接在 BEFORE INSERT/UPDATE 触发器里执行复杂查询（比如跨表 JOIN 检查余额、查状态树）极易引发行锁升级甚至死锁，尤其在高并发写入场景下。MySQL 默认事务隔离级别下，触发器内 SELECT 会加读锁，若再碰上被更新的主键或索引字段，就可能堵住其他事务。
实操建议：
- 校验逻辑尽量轻量：只查必要字段，用覆盖索引，避免
SELECT *或无索引 WHERE - 禁止在触发器中调用存储过程或发起远程 HTTP 请求
- 对必须关联的业务表，优先查缓存视图或冗余字段（如把
order_status冗余到order_item表），而非实时 JOIN - 若校验失败需报错，统一用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'xxx'，别用SELECT ... INTO模拟异常
PostgreSQL 的触发器函数为什么总报 missing FROM-clause entry for table xxx
这是 PostgreSQL 特有语法陷阱：触发器函数内部不能直接引用 NEW/OLD 行的字段名作为子查询的表别名，比如写 SELECT id FROM NEW 是非法的；你得显式声明变量或用 ROW() 构造。
常见错误写法：
SELECT amount FROM NEW WHERE user_id IN (SELECT user_id FROM users WHERE is_blocked = true);
正确做法是把校验逻辑拆成两步：
- 先在触发器函数开头声明变量：
DECLARE blocked_user BOOLEAN; - 再用
SELECT is_blocked INTO blocked_user FROM users WHERE id = NEW.user_id; - 最后用
IF blocked_user THEN SIGNAL ... END IF;
注意：PostgreSQL 触发器函数返回值必须是 TRIGGER 类型，结尾务必写 RETURN NEW;（INSERT/UPDATE）或 RETURN OLD;（DELETE），漏写会导致数据写入静默失败。
SQL Server 的 AFTER 触发器没法阻止插入，怎么补救
AFTER INSERT 触发器执行时，数据已落盘，此时抛异常（RAISERROR）只能回滚事务，但调用方未必捕获——用户看到的是“成功插入”，后台日志却显示回滚，体验割裂。
真正能拦截的只有 INSTEAD OF 触发器，但它不支持对视图以外的普通表创建（SQL Server 限制）。所以实际方案是：
- 把校验逻辑前置到应用层或存储过程中，用
TRY...CATCH包裹 INSERT + 校验查询 - 若必须用触发器，改用
INSTEAD OF INSERT在视图上做代理，让应用写视图而非基表 - 或者启用
CONTEXT_INFO配合应用传标记，让触发器识别“本次是否允许跳过校验”，避免循环触发
另外，SQL Server 触发器里禁止使用 GETDATE() 以外的非确定性函数（如 NEWID()），否则无法创建索引视图，这点容易被忽略。
触发器校验和应用层校验该选哪个
触发器不是银弹。它保证数据库层面强一致性，但代价是耦合度高、调试困难、迁移成本大。比如 MySQL 切到 TiDB 后，触发器语法兼容性差，部分特性（如 FOR EACH ROW 子句行为）不一致。
推荐分层策略：
- 核心约束（如外键、非空、唯一）交给 DDL 定义，最高效也最通用
- 跨表业务规则（如“订单金额不能超过客户信用额度”）优先走应用层 + 分布式事务（Saga/TCC），留触发器作兜底
- 只对遗留系统或无法修改应用代码的场景，才用触发器硬控，且必须配套单元测试（用
INSERT ... SELECT模拟各种边界数据）
最麻烦的是时间窗口问题：触发器校验基于当前事务快照，而应用层可能刚更新了 A 表、还没提交，B 表触发器去查 A 表就看不到最新值——这种时序依赖，光靠触发器根本解不了。
