触发器中禁止耗时操作，应改用异步方案：MySQL 用消息表 + 轮询，PostgreSQL 优先用 LISTEN/NOTIFY；需保障幂等、唯一 ID、上下文完整及超时重试。
触发器里直接调用耗时操作必然拖垮事务
SQL 触发器运行在主事务上下文中，INSERT/UPDATE/DELETE 不完成，触发器不返回，整个事务就卡着。哪怕只是多查一次远程 API、写日志到慢盘、或发一封邮件，都可能让 LOCK WAIT TIMEOUT EXCEEDED 或 Transaction timeout 频繁报出。
常见错误现象：业务接口偶发 504，数据库监控显示 innodb_row_lock_time_avg 突增，慢查询日志里看不到大 SQL，但事务等待时间明显拉长。
- 触发器中禁止出现任何网络 I/O（如
curl、http_request）、文件写入、跨库查询 - 避免在触发器中调用存储过程，除非该过程已明确验证为纯内存计算、无锁、毫秒级完成
- MySQL 8.0+ 的
VALIDATE PASSWORD类插件函数也需警惕——某些配置下会隐式触发磁盘读
用「插入消息表 + 定时轮询」替代同步触发逻辑
最轻量、兼容性最强的解法：把原本想在触发器里干的事，改成往一张专用消息表里插一条记录，再由外部进程异步消费。不改应用代码，不依赖消息中间件，MySQL 原生支持。
使用场景：审计日志落 ES、订单变更通知下游系统、库存扣减后更新缓存等——只要不要求“实时”，只要求“最终一致”。
- 建表：
CREATE TABLE trigger_queue (id BIGINT AUTO_INCREMENT PRIMARY KEY, event_type VARCHAR(32), payload JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP) - 原触发器只保留：
INSERT INTO trigger_queue (event_type, payload) VALUES ('order_updated', JSON_OBJECT('order_id', NEW.id, 'status', NEW.status)) - 外部消费者用
SELECT …… FOR UPDATE SKIP LOCKED安全取任务，处理完再DELETE，避免重复消费
PostgreSQL 用户优先考虑 LISTEN/NOTIFY + worker 进程
比起轮询，LISTEN/NOTIFY 是 PostgreSQL 原生的轻量事件通知机制，无轮询延迟、无额外表压力、事务提交即触发。
性能影响极小：通知本身不写 WAL，仅内存广播；worker 进程可按需启停，扩容简单。
- 触发器内只需一行：
PERFORM pg_notify('order_events', json_build_object('id', NEW.id, 'action', 'updated')::text); - worker 用
LISTEN order_events订阅，收到 payload 后解析执行业务逻辑 - 注意：NOTIFY 不保证投递成功，worker 需自带重试 + 死信记录（例如写入
notify_failure_log表）
别忽略事务边界和幂等设计
拆出去的逻辑不再是原子的一部分，失败不会回滚主事务。这意味着：你删掉触发器那一刻，就主动放弃了 ACID 中的“A”（原子性）和“C”（一致性），换来了“A”（可用性）和“P”（分区容忍）。
容易被忽略的点：上游事务已提交，但异步任务失败三次后进死信队列——此时业务状态已是“已生效”，而下游却没收到。用户看到订单已支付成功，但积分没到账。
- 所有异步任务必须带唯一业务 ID（如
order_id:updated:202405211422），用于去重和幂等判断 - 消息表或 NOTIFY payload 中必须包含足够上下文，禁止依赖“当前数据库快照”——因为执行时原记录可能已被覆盖
- 给异步任务设合理超时（比如 30 秒），超时即记为失败，而非无限重试阻塞队列
