触发器同步一压就垮，因其在事务内同步执行，高并发下导致锁等待堆积、连接池耗尽、响应飙升；根本原因是将最终一致性任务塞入强一致性事务。应改用轻量消息解耦：触发器仅写简表或发binlog，由外部消费者异步处理。

为什么触发器同步一压就垮？ 因为触发器在事务内同步执行，每条 INSERT/UPDATE 都会卡住主流程等它干完——哪怕只是发个通知、写个日志、调一次 dblink。高并发下，锁等待堆积、连接池耗尽、响应时间飙升，AFTER INSERT 变成 AFTER WAIT。

常见错误现象包括：

• SHOW PROCESSLIST 里大量 Updating 或 Waiting for table metadata lock
• Innodb_row_lock_waits 指标突增，但业务 SQL 本身很简单
• 同步延迟从毫秒跳到秒级，且随 QPS 线性恶化

根本原因不是“用了触发器”，而是把“最终一致性任务”硬塞进了强一致性事务边界。

怎么把重逻辑从事务里摘出来？ 核心动作就一个：用轻量消息替代直接操作。触发器只做一件事——往一张极简表里插入一条记录，或写入 binlog（MySQL）/logical decoding（PostgreSQL），其余全交给外部消费者。

实操建议：

• 创建一张仅含 event_id、table_name、pk_value、op_type、created_at 的 sync_event_log 表，引擎用 InnoDB，主键明确，不加冗余索引
• 触发器里只执行 INSERT INTO sync_event_log VALUES (...)，不查关联表、不 JOIN、不调函数
• 用 Canal（MySQL）或 pg_recvlogical + 自定义解析器（PostgreSQL）监听变更，把 sync_event_log 新增行转成 Kafka 消息
• 独立服务消费 Kafka，按需做跨库更新、缓存刷新、ES 写入等——这些操作失败可重试，不影响主库事务

注意：不要在触发器里直接 INSERT INTO remote_db.remote_table，dblink 调用是同步阻塞的，网络抖动就会拖垮整个事务。

PostgreSQL 用 dblink 同步时特别容易踩什么坑？dblink 看似方便，实则暗藏三重风险：事务不可见、连接泄漏、错误静默。

典型问题：

• 主事务还没提交，dblink_exec 却已把数据写进远端库 → 主库回滚，远端数据变孤儿
• 每次调用 dblink_connect 开新连接，没配 dblink_close_all() → 连接数暴涨，too many clients already 报错
• dblink_exec 报错不抛出异常，只返回错误字符串 → 触发器看似成功，实际同步丢失

正确做法：

• 放弃在触发器中直连远端库，改走消息中间件
• 如果必须用 dblink（如极低延迟要求），务必用 dblink_send_query + dblink_get_result 异步模式，并包裹在 BEGIN ... EXCEPTION 块中显式处理失败
• 所有 dblink_connect 必须配对 dblink_disconnect，且不能依赖自动清理

消息中间件选型和落地关键点 不是所有 MQ 都适合这个场景。重点看三点：顺序保障、投递语义、运维成本。

推荐组合：

• MySQL 生态优先用 Canal + Kafka（顺序严格、吞吐高、社区成熟）
• PostgreSQL 推荐 pg_recvlogical + RabbitMQ（轻量、ACK 明确、调试友好）
• 避免用 Redis Stream 做核心同步通道——无内置死信、无消费组位点管理，故障恢复难

落地时容易忽略的细节：

• Kafka topic 必须开启 enable.idempotence=true，防止重复消息引发双写
• 消费服务要实现幂等写入，比如用 INSERT ... ON CONFLICT DO NOTHING 或基于 event_id 去重表
• 触发器写 sync_event_log 前，先检查是否已存在同 pk_value + op_type 的未消费记录，避免批量更新时刷出重复事件

真正难的不是“怎么接入 Kafka”，而是界定哪些字段变更必须实时同步、哪些可以接受 2 秒延迟、哪些压根不该走数据库链路——这需要和业务方一起画清楚状态流转图，而不是让 DBA 在触发器里不断打补丁。