慎用SQL触发器代替后端中间件业务逻辑，根本原因是其运行在数据库事务上下文中，导致不可观测、难调试、无法解耦、易拖垮并发——它本质是隐式执行的“黑盒事务放大器”，违背高并发、可观测、易回滚、强协同原则。
慎用 SQL 触发器代替后端中间件业务逻辑，根本原因是：触发器运行在数据库事务上下文中，无法解耦、不可观测、难调试、易拖垮并发——它不是轻量钩子，而是隐式执行的“黑盒事务放大器”。
触发器让业务链路彻底隐身
后端中间件（如 Spring Boot 服务、Node.js Worker）的日志、链路追踪（OpenTelemetry）、监控指标（QPS/耗时/错误率）全部可埋点、可采样、可告警。而触发器完全游离于这套体系之外：
- APM 工具抓不到触发器内执行的
UPDATE logistics_events或INSERT INTO audit_log -
SHOW PROCESSLIST只显示UPDATE orders，不体现它背后触发了 3 层嵌套逻辑 - 慢 SQL 告警只报主语句耗时，但 800ms 中有 720ms 花在触发器查
sku_info表且没走索引 - 线上排查“为什么订单状态没同步？”时，得先手动查
INFORMATION_SCHEMA.TRIGGERS，再翻定义，再猜执行路径
触发器天然破坏事务边界与协作契约
中间件通过明确的接口定义（如 REST / gRPC）、重试策略、降级开关、分布式事务协调（Seata/XA）来管理跨系统协作；触发器则把所有动作硬塞进单个数据库事务，导致：
- 调用外部短信服务失败 → 整个下单事务回滚，但库存可能已在触发器外扣减（ORM 乐观锁 + 触发器 UPDATE 冲突）
- 触发器里
UPDATE user_stats持有行锁，而另一事务正读该用户积分 → 锁等待蔓延，下游结算卡住 - DDL 触发器依赖
EVENTDATA()解析 XML，字段名拼错就静默失败，连错误日志都不抛 - Azure SQL / Fabric 不支持 CLR 触发器，原来用
EXTERNAL NAME调 .NET 方法的逻辑直接不可用
批量操作下性能断崖式恶化
中间件可对批量请求做合并、异步化、分片处理；触发器面对 INSERT INTO orders SELECT * FROM staging_orders LIMIT 10000 时，只能按行硬扛：
- MySQL/PostgreSQL 默认
FOR EACH ROW，1 万行 = 执行 1 万次相同逻辑（哪怕只是INSERT INTO log） - SQL Server 若未关
RECURSIVE_TRIGGERS，触发器里UPDATE orders可能递归上千层 - 用
SELECT @val = amount FROM inserted这类标量假设写法，批量插入时只取第一行，其余 9999 行校验失效 - 想优化？不行——触发器不支持
NOLOCK对写操作提速，也不支持执行计划缓存复用
维护和迁移成本远超预期
中间件代码在 Git 里版本可控、可 Code Review、可单元测试；触发器散落在数据库中，极易被忽略：
-
mysqldump默认不导出触发器，备份恢复后行为突变，无人察觉 - 开发改了应用层订单逻辑，忘了禁用旧触发器，新老逻辑双写冲突（如两次扣库存）
- 测试环境常关闭触发器省事，功能测试通过，上线后因触发器逻辑缺陷导致数据不一致
- 迁移到分布式数据库（如 TiDB、CockroachDB）或云数仓（Fabric）时，多数触发器语法不兼容，必须重写甚至重构整条链路
最常被忽略的一点：触发器不是业务逻辑的缓冲区，而是数据库职责的越界延伸。它只该做三件事——填 created_at、校验状态流转合法性、写轻量审计标记。其余所有“顺手加一下”的逻辑，都会在未来某次大促、某次迁移、某次故障排查中，变成压垮系统的最后一根稻草。
