触发器无法跨数据库平台实现增量数据捕获，因其仅响应本地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；
- 所有字段映射、类型转换、空值处理逻辑集中在消费端，不在数据库内硬编码。
触发器只适合同一实例内多库同步，或者极简场景下的本地变更落日志。跨平台这件事，从源头上就不该让它承担。
