触发器能直接做异地数据同步吗
答案是：不能。触发器本质上是一个“本地”的执行单元，它只在所属数据库的事务边界内活动，天生不具备跨网络访问远程节点的能力。有些开发者会尝试在 INSERT 触发器里调用 pg_notify 或通过 dblink 直连远程库，这种做法风险极高。它会导致本地事务被远程网络I/O阻塞，极易引发超时失败，甚至拖垮主库性能。更糟糕的是，一旦网络闪断，本地事务都可能因为无法完成触发器的全部操作而回滚失败，得不偿失。
为什么“基于时间”的同步不能靠触发器驱动
我们常说的“基于时间”同步，比如每隔一分钟去拉取 updated_at > ‘某时间点’ 的记录，这其实是一种变更数据捕获（CDC）的下游消费逻辑。触发器在这里完全使不上劲，因为它只响应单条SQL语句的瞬间动作，无法回答几个关键问题：上次同步到哪里了？中间有没有记录被遗漏？如果目标端数据有冲突该怎么处理？
市场上不乏这样的误用案例，通常表现为：
- 在触发器里插入一条日志到
sync_log表，再指望外部定时任务来读取——但高并发下日志的顺序无法保证，原子性更是无从谈起。 - 试图在触发器里调用
curl发送HTTP请求——数据库进程通常没有外网权限，超时和权限管控都是噩梦。 - 依赖
current_timestamp做判断，却忽略了事务提交时间与触发器执行时刻可能存在延迟，最终导致数据漏同步。
真正可行的替代方案：轻量级 CDC + 时间戳字段
正确的思路是把“数据变更的标记”和“数据的同步动作”彻底解耦。让数据库只负责打好标记（比如更新时间戳），把同步工作交给独立的、健壮的进程来按时间窗口拉取。
具体操作上，有这么几个要点：
- 统一时间戳字段：确保每张需要同步的表都有一个可靠的
updated_at字段。在MySQL中，可以设置为NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP；如果是PostgreSQL 12及以上版本，可以考虑使用生成的列：GENERATED ALWAYS AS (CURRENT_TIMESTAMP) STORED。 - 选择捕获方式：优先使用
pg_logical（PostgreSQL）或解析binlog（MySQL）来捕获变更，这比轮询时间戳更精准、延迟更低。如果必须采用轮询，那么同步脚本必须维护一个可靠的last_sync_time状态（存于文件或配置表），每次查询使用WHERE updated_at > ?，并且务必加上ORDER BY updated_at, id来保证顺序和避免重复。 - 实现写入幂等：数据写入异地节点前，必须加入幂等校验。PostgreSQL 可以用
INSERT ... ON CONFLICT (id) DO UPDATE，MySQL 则可以考虑INSERT IGNORE或REPLACE INTO，这是避免因重试产生脏数据的关键。 - 警惕触发器嵌套：切记，不要在触发器里去修改
updated_at字段。这个字段应该由应用层或ORM来控制，否则可能引发触发器嵌套执行，覆盖掉真实的业务更新时间。
如果非要用触发器参与同步流程，只能做日志登记
如果架构上确实需要触发器提供“信号”，那么唯一安全的做法是让它只做一件事：向一个本地的、轻量的变更日志表里写入记录，然后立刻退出。后续的同步工作，交给另一个独立的消费者进程异步处理。
这种模式下，必须遵守几个规则：
- 日志表要够“轻”：使用
UNLOGGED表（PostgreSQL）或MEMORY引擎表（MySQL）来最大限度降低对主业务事务的性能影响。 - 触发器要够“纯”：触发器的逻辑只能是简单的
INSERT INTO sync_queue (table_name, row_id, op_type, ts)，绝不进行远程查询、网络请求或调用复杂函数。 - 消费要够“稳”：消费者进程使用
SELECT ... FOR UPDATE SKIP LOCKED这样的模式来安全地拉取未处理记录，处理成功后及时删除或标记状态，避免重复消费。 - 清理要够“及时”：必须为
sync_queue这类日志表设计TTL清理策略，比如使用分区表并按天切分，防止其无限膨胀拖慢系统。
最后提个醒：时间字段的精度和时区必须统一，建议全部使用 TIMESTAMP WITH TIME ZONE 或转换为UTC存储，否则跨时区同步就是一场灾难。监控同步延迟时，别只看时钟差，要对比源库的 MAX(updated_at) 和目标库已确认同步到的最大值——这个差值，才是真实的滞后时间（lag）。
