Sql server 合并复制实际存储数据的位置？

我读过一些非官方文章，其中说合并复制实际上将数据存储为事务，并将其复制为事务。但是MSDN上没有关于这方面的官方信息，也没有我能找到的任何官方来源

拜托，有人能帮我说清楚吗？如果它存储事务-在

MSMerge\u contents

中是否有指向相应事务的链接？为什么它会像它说的那样过滤插入/更新/删除

如果它不复制事务，它将在何处存储用于复制的实际数据

我个人认为合并复制不使用事务日志存储数据

表触发器（MSmerge triggers）转换增量生成信息中的每个事务，并将该信息存储在系统元数据表MSmerge_contents、MSmerge_tombstone和MSmerge_genhistory中，您可以通过tablenick连接每个表，并使用rowguid列查找行（用于MSmerge_contents和MSmerge_tombstone）

复制代理比较发布服务器和订阅服务器的MSmerge_内容的内容，它复制新行并更改现有行，具体取决于行GUID列和每行的生成编号。它使用实际表中的实际行，通过rowguid连接。 MSmerge_墓碑表也是如此

---

它不使用事务日志。它甚至没有日志读取器处于活动状态。

合并复制或就此而言，任何类型的复制总是从快照初始化的初始步骤开始，在发布服务器上创建所有数据和对象的快照，并发送给所有订阅服务器。（在此步骤中，实际数据从发布服务器移动到订阅服务器）

事务性复制

将初始快照交付给订阅服务器后，对于事务复制，SQL Server将从发布服务器读取事务日志并将其推送到分发服务器，分发服务器将（或订阅服务器拉取，具体取决于订阅服务器的类型）日志发送给所有订阅服务器。这些日志通过触发器和一些元数据表在订阅服务器上重播

合并复制

在合并复制中将初始快照交付给订阅服务器后，SQL Server将开始从发布服务器和所有订阅服务器读取事务日志，并将其发送到合并代理（此代理仅适用于合并复制，在任何其他类型的复制中都不存在），合并代理使用特定的算法对插入/更新/删除应用于所有参与订阅服务器和发布服务器的顺序进行排序（通常先删除，然后应用更新和最后插入），一旦合并代理排序了顺序，日志在分发服务器上排队，就像在事务复制中一样，并被推/拉到订阅服务器

---

数据移动只发生在第一步（快照初始化），之后就是日志和代理移动并同步数据。我希望这有帮助

那么，合并复制的合并表触发器的用途是什么呢？它们维护合并代理排序操作的顺序？如果一个事务有insert和delete-千个操作会被排序吗？合并代理将如何中断该事务以对千个操作进行排序？我已更改了我的问题-添加了“我自己的意见”部分。我应该回答你的问题。