跨Microsoft SQL Server与PostgreSQL数据库每日同步大表：如何识别源库已删除行以实现完整同步？

阿华AIGC实验室

2026-4-30

解决SQL Server到PostgreSQL同步时的删除操作捕获问题

针对你遇到的SQL Server（源库）到PostgreSQL（目标库）同步时无法捕获删除操作的痛点，结合3000万条数据量的场景，我分享几个实战验证过的可行方案，你可以根据自身权限、业务约束来选择：

方案1：启用SQL Server变更数据捕获（CDC）—— 最精准高效的方案

这是处理这类问题的首选方案，因为SQL Server原生支持CDC，能精准捕获所有增删改操作的细节，包括删除行的主键信息。

操作步骤：
1. 先对源数据库启用CDC：EXEC sys.sp_cdc_enable_db;
2. 对需要同步的目标表启用CDC：EXEC sys.sp_cdc_enable_table @source_schema='dbo', @source_name='your_table', @role_name='cdc_admin';
3. 之后可以通过系统表cdc.[schema_table]_CT获取变更记录，其中__$operation字段标记了操作类型：1=删除，2=插入，3=更新前镜像，4=更新后镜像
4. 同步逻辑中，专门读取__$operation=1的记录，提取主键字段，到PostgreSQL中执行对应的DELETE语句
优势：
- 无需修改业务表结构，不影响现有业务
- 仅捕获变更数据，增量同步效率极高，适合3000万级别的大数据量
- 能精准捕获所有物理删除操作
注意事项：
- 需要SQL Server的版本支持（2008及以上 Enterprise版，2016及以上 Standard版）
- 需要有足够的权限启用CDC，且要注意CDC日志的清理策略，避免占用过多存储空间

如果无法启用CDC（比如权限不足、版本不支持），可以通过改造源表的删除逻辑，用软删除替代物理删除：

操作步骤：
1. 在源表中添加两个字段：
  - is_deleted BIT DEFAULT 0：标记是否删除
  - last_updated DATETIME DEFAULT GETDATE()：记录最后修改时间
2. 修改所有业务中的删除逻辑，不再执行DELETE FROM table WHERE ...，而是改为UPDATE table SET is_deleted=1, last_updated=GETDATE() WHERE ...
3. 增量同步时，除了同步last_updated > 上次同步时间且is_deleted=0的新增/更新行，还要同步last_updated > 上次同步时间且is_deleted=1的行，到PostgreSQL中执行删除或标记软删除
优势：
- 实现简单，不需要依赖数据库高级特性
- 兼容大部分业务场景，对现有代码改造量可控
注意事项：
- 需要确保所有删除操作都通过软删除实现，避免遗漏物理删除的情况（可以通过触发器约束，阻止直接DELETE操作）
- 源表会增加额外字段，需要评估存储开销（3000万条数据的话，两个字段的开销很小）

如果前两个方案都无法实施，你可以优化现有的二分法思路，改用分片对比来提升效率：

核心思路：
1. 按主键（或唯一键）将数据划分为多个小分片，比如按ID每10万条一个区间（3000万条就是300个分片）
2. 定期（比如每天凌晨低峰期）对每个分片执行对比：
  - 对比源库和PG库中该分片的行数，如果行数不一致，说明该分片存在增删改
  - 更精准的方式是计算每个分片的行哈希总和（比如对每行的所有字段拼接后做MD5，再求和），哈希不一致则进一步排查
3. 找到不一致的分片后，再在该分片内逐行对比或用更小的分片细化，定位到具体删除的行，然后同步删除
优化点：
- 相比全局二分法，分片对比的粒度更细，能快速缩小不一致的范围，减少全量对比的开销
- 平时仍采用增量同步（基于更新时间戳），定期分片校验补全删除操作，平衡效率和数据一致性
注意事项：
- 必须依赖主键或唯一键来分片，否则无法有效划分区间
- 对比操作尽量在低峰期执行，避免影响业务性能