合并复制实际数据存储位置及相关机制求证

我来帮你澄清这些关于SQL Server合并复制的核心问题，结合官方原理和实际运行逻辑来拆解：

一、核心结论：合并复制不依赖事务日志存储或复制数据 #

这是合并复制和事务复制最本质的区别——它完全通过触发器捕获变更，而非读取事务日志，所以也不需要启动日志读取器代理。

二、MSmerge_contents与事务的关联？ #

MSmerge_contents表不存在与事务直接关联的字段。它存储的是被复制行的增量变更元数据，包括：

• rowguid：业务表行的唯一标识，用于关联实际数据行
• tablenick：对应业务表的标识，用来关联不同的复制表
• gen：当前变更所属的生成号，用于追踪同步进度
  这些数据都是由合并复制的专用触发器（比如MSmerge_ins_<表名>、MSmerge_upd_<表名>）在捕获业务表变更后写入的，和事务日志没有直接关联。

三、合并复制如何筛选插入/更新/删除操作？ #

合并复制的筛选逻辑是基于**生成号（generation）**和元数据表配合实现的：

1. 当业务表发生变更时，触发器会将该变更关联到当前的生成号，写入对应的元数据表（插入/更新写MSmerge_contents，删除写MSmerge_tombstone）
2. 合并代理在同步时，会先对比发布者和订阅者的MSmerge_genhistory表，找出双方未同步的生成号区间
3. 针对这个区间内的变更，代理会结合发布定义的筛选规则（行筛选、列筛选等），只提取符合条件的变更记录
4. 最后通过rowguid关联到业务表的实际行，完成对应插入/更新/删除的同步

四、复制用的实际数据存储在哪里？ #

合并复制的存储分为两部分：

• 变更元数据：存储在系统元数据表中：
  • MSmerge_contents：保存插入、更新的行变更信息
  • MSmerge_tombstone：保存已删除行的信息，用于同步删除操作
  • MSmerge_genhistory：记录各节点已处理的生成号，追踪同步进度
• 实际业务数据：依然存储在你自己的业务表中，合并代理通过rowguid字段将元数据表的变更信息和业务表的实际行关联，完成同步操作

补充：你的个人观点完全正确，再梳理下完整流程 #

合并复制的核心流程是触发器驱动的元数据捕获：

1. 业务表发生插入/更新/删除时，合并复制的专用触发器被触发
2. 触发器将变更转换为增量生成信息，写入对应的元数据表（插入/更新到MSmerge_contents，删除到MSmerge_tombstone）
3. 合并代理同步时，通过MSmerge_genhistory识别未同步的生成号范围，提取对应元数据
4. 用rowguid关联业务表的实际行，完成同步操作
   全程不会读取事务日志，也不需要日志读取器代理参与。

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