远程调用在触发器中不可回滚，因其脱离主事务上下文，主事务回滚时外部操作（如http请求、跨库调用）无法撤销，导致数据不一致；且同步阻塞、超时风险高、权限失控、缺乏重试与可观测性。
因为这会直接阻塞主事务、放大超时风险、破坏数据一致性，且无法回滚外部副作用。
远程调用在触发器中根本不可回滚
触发器运行在主 DML 事务上下文中，但远程操作（如调用另一数据库的存储过程、发 HTTP 请求、写消息队列）不在该事务管辖范围内。一旦主事务因其他原因回滚，远程端已完成的操作无法撤销——比如订单插入失败了，但库存已扣减、短信已发出，状态彻底不一致。
- MySQL/PostgreSQL 不支持跨库事务，SQL Server 的分布式事务（MSDTC）开销巨大且默认禁用
- 常见错误是误以为
CALL remote_proc()或EXEC http_post能被包含进原子性保障，实际完全不能 - 即使远程调用成功返回，只要主事务后续失败，应用层看到的就是“半成功”脏状态
网络延迟会拖垮整个写入链路
触发器同步执行，每行变更都必须等远程调用完成才能继续。批量插入 1000 行订单？意味着 1000 次网络往返，哪怕平均延迟 200ms，光等待就耗掉 200 秒，远超数据库连接超时阈值（通常 30s）。
- 错误现象：
Timeout expired. The timeout period elapsed prior to completion of the operation - 高并发下极易触发连接池耗尽、线程阻塞、主库 CPU 拉满
- MySQL 的
max_connect_errors可能因频繁超时被触发，导致 IP 被临时封禁
权限与可观测性完全失控
触发器以定义者身份执行，常被赋予过高权限（如 root 或 db_owner），而远程调用又把这种权限扩散到外部系统；同时，日志分散在数据库、中间件、第三方服务三处，出问题时根本无法关联定位。
- 典型风险：触发器里用
SELECT ... INTO OUTFILE或调用sys_exec写文件，可能被利用提权 - 审计日志只记录“触发器已执行”，不记录远程调用是否真正送达或失败
- 监控指标（如慢查询日志）只显示
INSERT耗时暴涨，但看不出瓶颈其实在外部 API
最常被忽略的是：触发器不是 RPC 客户端。它没有重试、熔断、降级能力，也没有请求上下文透传机制。真要联动外部系统，唯一可控的方式是写轻量变更事件（如插入 outbox 表），再由独立消费者异步处理——这样失败可重试，不影响主流程，也能保证最终一致性。
