合并复制概述
与事务复制相同，合并复制通常也是从发布数据库对象和数据的快照开始，并且用触发器跟踪在发布服务器和订阅服务器上所做的后续数据更改和架构修改。订阅服务器在连接到网络时将与发布服务器进行同步，并交换自上次同步以来发布服务器和订阅服务器之间发生更改的所有行。
合并复制通常用于服务器到客户端的环境中。合并复制适用于下列各种情况：
多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅服务器。
订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
每个订阅服务器都需要不同的数据分区。
可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。
应用程序需要最终的数据更改结果，而不是访问中间数据状态。例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（也就是第五次更改的值）。
合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。由于更新是在多个节点上进行的，同一数据可能由发布服务器和多个订阅服务器进行了更新。因此，在合并更新时可能会产生冲突，合并复制提供了多种处理冲突的方法。
若要跟踪更改，带有排队更新订阅的合并复制和事务复制必须能够唯一地标识每个已发布表中的每一行。为了完成此操作，合并复制将列 rowguid 添加到每个表，除非该表已有数据类型为 uniqueidentifier 且设置了 ROWGUIDCOL 属性的列（在此情况下使用此列）。如果从发布中删除该表，则删除 rowguid 列；如果将现有列用于跟踪，则不删除该列。筛选器不能包含复制用于标识行的 rowguidcol。提供 newid() 函数作为 rowguid 列的默认值，但是用户可以根据需要为每个行提供 guid。但是，不提供值 00000000-0000-0000-0000-000000000000。
有关如何实现合并复制的信息，请参阅设计和实现（复制）。
有关涉及合并复制的常见方案的信息，请参阅在服务器和客户端之间复制数据。