触发器同步一压就垮，因其在事务内同步执行，高并发下导致锁等待堆积、连接池耗尽、响应飙升；根本原因是将最终一致性任务塞入强一致性事务。应改用轻量消息解耦：触发器仅写简表或发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 在触发器里不断打补丁。
