如何使用SQL触发器实现跨数据库平台的增量数据捕获

触发器无法跨数据库平台实现增量数据捕获，因其仅响应本地DML事件、inserted/deleted表作用域限于当前实例，且无法解析异构日志格式、缺乏统一操作类型标识、时间戳精度与类型系统不兼容，强行模拟易导致静默失败或数据丢失。

不能用 SQL 触发器直接实现跨数据库平台（比如 SQL Server → MySQL）的增量数据捕获。触发器是数据库引擎内部的同步钩子，它跑在源库上下文中，既读不到目标库的 binlog/WAL，也无法跨平台解析事务日志或保证语义一致性。

为什么触发器无法跨平台捕获增量

触发器只响应本地 DML 事件，它的 inserted 和 deleted 表仅在当前数据库实例内有效，生命周期随事务结束而销毁。跨平台意味着： - MySQL 的 binlog、PostgreSQL 的 WAL、SQL Server 的 transaction log 格式互不兼容，触发器没能力解析； - 没有统一的 op_type 字段——SQL Server 触发器里 TG_OP 是 PostgreSQL 特有，MySQL 根本不提供； - 时间戳精度不一致：GETDATE()（SQL Server）、NOW(6)（MySQL）、CLOCK_TIMESTAMP()（PG）返回值不可比，无法排序定序； - 类型系统差异导致隐式转换失败：比如 SQL Server 的 datetime2(7) 写入 MySQL 的 datetime 会截断微秒，且无报错提示。

试图用触发器“模拟”跨平台同步的典型失败点

• 在 SQL Server 触发器里拼 OPENQUERY 发送到 MySQL 链接服务器：必须装 ODBC 驱动 + 注册 provider + 开启 Ad Hoc Distributed Queries，而 MySQL ODBC 对 INSERT ... ON DUPLICATE KEY UPDATE 等语法支持不全，常静默失败；
• 用触发器写本地 cdc_log 表，再由外部脚本轮询同步：脚本若未按 txid 或单调递增序列消费，遇到网络中断就会跳过部分变更；
• 依赖 last_modified 字段做增量：但该字段由应用层更新，若某次 UPDATE 忘记设值，或批量导入绕过触发器，这条记录就永远丢失；
• 把 INSERTED 转 JSON 后 HTTP POST 到中间服务：触发器内调用 sp_OACreate 已被默认禁用，且超时设置不可控，一次请求卡住整个事务。

真正可行的跨平台增量路径

放弃触发器作为捕获主体，改用日志解析类方案： - SQL Server 侧启用 CDC（需 Enterprise 版）或 Change Tracking（轻量但不捕获 old 值）； - MySQL 侧监听 binlog（ROW 格式），用 Debezium 或 Maxwell 解析； - 中间用 Kafka 或 Pulsar 做缓冲，确保至少一次投递； - 消费端按 table + pk 做幂等写入，对 MySQL 目标表用 INSERT ... ON DUPLICATE KEY UPDATE 或临时表 merge； - 所有字段映射、类型转换、空值处理逻辑集中在消费端，不在数据库内硬编码。

触发器只适合同一实例内多库同步，或者极简场景下的本地变更落日志。跨平台这件事，从源头上就不该让它承担。