问题描述：      transaction分为许多cmd。执行cmd之后也可能执行触发器。我想搞清楚transaction的cmd和订阅者触发器之间，cmd和cmd之间，transaction和transaction之间的运行先后顺序。 Ps：这里不详细考察发布者、分发者，忽略具体的细节，只把结构简化为发布者——订阅者   问题结论： 1）      对于一个transaction，           对每个cmd，先上锁、执行cmd以更新Subscriber，然后等Subscriber触发的一连串事情都运行完后，才解锁、完成cmd；           一个cmd完成后，才执行下一个cmd，即线性执行；            对每个transaction，           一个transaction宣告完成后，才执行下一个transaction，即线性执行             探究使用的工具：      sys.dm_tran_locks，复制监视器，优化器提示，触发器，WAITFOR   问题探究： 1）在一个transaction只有一个cmd的情况下，cmd和订阅者触发器的运行顺序      Publisher的数据库为SourceExam，含有TestTrigger和TestTriggerDst两个表。没有触发器。      Subscriber的数据库为DstExam，包含表TestTrigger和TestTriggerDst。表TestTrigger上包含触发器，且不开启NOT FOR REPLICATION选项，如下                 让发布者发布一个能在Subscriber处触动触发器的事务，然后运行如下语句                 会发现，发布者也在等待，其lastwaittype是WAITFOR，而且长期持有数据行上面的X锁和数据所在页面的IX锁。说明写事务还没全部完成。      而此时用优化器提示with (nolock)来做SELECT操作，会发现，Subscriber表里的数据已经被更新。说明写事务内容本身已经做完了。      等到WAITFOR的时间结束后，用上述查看锁的语句发现，写事务已经消失，说明写完成了。      所以，我们大胆推断：           对于单个cmd的处理，先上锁、执行对Subscriber的更新，然后等Subscriber产生的一连串事情都运行完后，才解锁、完成。     2）在一个transaction有多个cmd的情况下，cmd和cmd之间的运行顺序      Subscriber的TestTrigger表上的触发器改为如下                 同时，Publisher也设置一个触发器，内容为更改TestTriggerDst的数据。然后，发布一个能激发Publisher和Subscriber触发器的事务。这样，复制监视器里会显示：                           然后可以看到，这回事务发布失败，可看到下述复制监视器里的消息。说明第一个cmd的删除执行之后，才执行第二个cmd                 这说明，第一个cmd的触发器要运行完毕，才能运行第二个cmd。可大胆猜想：           第一个cmd宣告运行完后，第二个cmd才能运行   另外，发生错误后，在Subscriber处发现TestTriggerDst依然存在。这是因为一个执行不成功的transaction会被回滚。   3）在有多个transaction的情况下，transaction和transaction之间的运行顺序      Subscriber的TestTrigger表上的触发器改为如下                 同时，利用GO语句或BEGIN TRANSACTION语句分别发送两个事务，事务A用于触动Subscriber的触发器，事务B则执行对TestTriggerDst的修改。然后，根据上述sys.dm_tran_locks的查询代码，可以判断第一个事务还在处理中；此时查询事务B修改的那个表，看事务B是否已执行。结果发现，在事务A未宣告完成期间，事务B不会得到执行，所以，我们大胆推断：           第一个transaction宣告运行完毕后，第二个transaction才开始运行