必须覆盖所有写入路径，否则数据一致性失效；触发器不能调用HTTP接口；BEFORE UPDATE中改状态易致逻辑错乱；查关联表须显式加FOR UPDATE锁。
该规则是否必须覆盖所有写入路径
这是决定放哪层的首要判断。如果 DBA 直接 UPDATE、ETL 工具用 COPY 或 BULK INSERT、跨库 CDC 同步写入——这些路径完全绕过应用层，也绕过大多数触发器（除非显式启用，如 PostgreSQL 的 TRIGGERS 选项）。此时若业务逻辑只在应用里，数据一致性立刻失效。
常见误判场景：
- 以为“所有写入都走 API” → 忘了运维可能手动修数据
- 以为“ETL 脚本会调用 SDK” → 实际直接连 DB 写裸表
- 以为“微服务间调用都受网关控制” → 忘了定时任务或批处理作业直连数据库
AFTER INSERT 中调用 HTTP 接口为什么一定失败
MySQL 原生不支持网络 I/O，SELECT 或 INSERT 触发器里执行 CURL、HTTP_GET 等函数会直接报错；PostgreSQL 需额外安装 http 扩展且默认禁用；SQL Server 虽可通过 sp_OACreate 调用 COM 对象，但极不稳定、权限难控、事务无法回滚。
更本质的问题是：HTTP 请求超时、重试、幂等、降级策略，数据库根本无法提供。一旦接口失败，你只能选择静默丢弃（破坏一致性）或抛异常中断事务（阻塞主流程），两者都不合理。
正确做法：
- 触发器只写轻量消息到本地表（如
notify_queue），字段含event_type、payload_id、created_at - 由独立消费者服务轮询或监听 binlog / logical decoding 拉取并处理
- 应用层发起的请求，仍由应用自己负责重试与补偿
BEFORE UPDATE 里偷偷改 status 字段有多危险
应用层读取旧值做分支判断（如 if order.status == 'pending'），而触发器在 BEFORE UPDATE 中已把 status 改为 'confirmed'，但该变更尚未提交。在 READ COMMITTED 隔离级别下，其他并发事务看不到这个新值，导致状态机逻辑错乱。
典型后果：
- 用户点击“确认订单”，前端显示成功，但后台因状态已变跳过风控校验
- 两个并发请求同时操作同一订单，一个被触发器提前锁死状态，另一个却按旧状态执行了退款
- 应用日志记录的是原始
status，而数据库实际存的是触发器改后的值，排查时对不上
真正安全的做法是：状态变更必须由应用明确发起，并通过 WHERE status = 'pending' + FOR UPDATE 加锁，确保读-改-写原子性。
触发器里查关联表没加 FOR UPDATE 就算完事
比如订单明细更新后，触发器要重算总金额：SELECT SUM(amount) FROM order_items WHERE order_id = NEW.order_id。这条语句默认是快照读，在高并发下极易读到旧版本数据，导致最终 order.total 被覆盖丢失。
这不是触发器的锅，而是忘了它运行在普通事务上下文中——它不自动获得任何额外隔离保障。
可行方案：
- 需要强一致：改用
SELECT SUM(amount) FROM order_items WHERE order_id = NEW.order_id FOR UPDATE，但会增加锁竞争 - 接受最终一致：触发器只记录变更事件，交由异步任务聚合，用物化视图或 Redis 原子计数器缓存实时值
- 根本规避：用数据库原生计算列（PostgreSQL
GENERATED ALWAYS AS）或约束替代
复杂点不在语法，而在你是否意识到：触发器不是魔法，它只是另一段跑在事务里的 SQL。所有你在应用里要考虑的并发、锁、隔离级别、回滚语义，它一样要面对。
