使用SQL Server触发器迁移数据到MongoDB是否有风险？有什么更优方案？

• 业务侧性能影响高：触发器逻辑与源表AutoPushData_OK的增删改操作处于同一事务内，每次业务写入都需要额外执行JSON序列化、MigrateData表写入操作，高并发场景下会大幅提升事务耗时、增加锁冲突概率，甚至出现业务操作因触发器逻辑异常被回滚的情况，直接影响原有业务可用性。
• 批量操作兼容性差：当源表出现批量插入、批量更新、批量删除操作时，FOR JSON AUTO会将整批数据序列化为单条大JSON存入MigrateData，既会大幅占用SQL Server存储，也会给下游同步服务的解析、写入MongoDB带来额外压力，甚至出现内存溢出、写入超时问题。
• 数据一致性难保障：
  1. 触发器仅能捕获部署完成后的增量变更，历史全量数据需要单独同步，全量同步过程中产生的增量容易出现衔接遗漏、重复的问题；
  2. 无内置的变更顺序标识，下游同步服务如果出现异常重启，很容易出现漏读、重复读取变更的问题，导致MongoDB和SQL Server数据不一致；
  3. 源表如果执行DDL变更（比如新增字段、修改字段类型、修改表名），如果不同步修改触发器逻辑，会出现变更漏捕获、数据格式异常的问题。
• 维护成本高：如果后续需要同步的表增加，每个表都需要单独编写、部署触发器，触发器的状态监控、异常排查难度远高于原生功能。

根据同步的周期要求可以选择两种方案：

临时迁移（一次性全量+短期增量同步） #

• 开启SQL Server原生的**变更数据捕获（CDC）**功能：SQL Server 2008及以上企业版/2016及以上标准版均支持该功能，无需侵入业务事务，开启后会自动在后台解析事务日志，将所有增删改变更写入系统自带的CDC表，且所有变更自带唯一LSN（日志序列号）保证顺序。你可以先记录当前LSN，完成全量历史数据同步后，再从记录的LSN点位开始拉取增量变更同步到MongoDB，完全避免数据遗漏、重复问题，性能开销远低于触发器方案。

长期异构数据同步 #

• 采用成熟的CDC采集工具：比如Debezium，直接对接SQL Server的事务日志/CDC接口，自动解析为标准的变更事件，内置断点续传、幂等处理能力，可直接配置将变更写入MongoDB，不需要自行开发、维护同步服务，稳定性、性能都远高于自研方案。
• 全量同步阶段可以直接使用SQL Server自带的bcp工具、SSIS组件批量导出源表数据，批量写入MongoDB，同步效率远高于逐行同步。

内容的提问来源于stack exchange，提问作者LamND7