《Replication的犄角旮旯》系列导读
Replication的犄角旮旯（一）--变更订阅端表名的应用场景
Replication的犄角旮旯（二）--寻找订阅端丢失的记录
Replication的犄角旮旯（三）--聊聊@bitmap
Replication的犄角旮旯（四）--关于事务复制的监控
Replication的犄角旮旯（五）--关于复制identity列
Replication的犄角旮旯（六）-- 一个DDL引发的血案(上)（如何近似估算DDL操作进度）
Replication的犄角旮旯（七）-- 一个DDL引发的血案(下)（聊聊logreader的延迟）
Replication的犄角旮旯（八）-- 订阅与发布异构的问题
Replication的犄角旮旯（九）-- sp_setsubscriptionxactseqno，赋予订阅活力的工具
---------------------------------------华丽丽的分割线--------------------------------------------
订阅与发布异构的情况并不常见，我们曾经的案例是对发布表扩充列长度时，避免长时间锁表而采用异构的方式，详见之前的博客
Replication的犄角旮旯（一）--变更订阅端表名的应用场景
对于异构产生的问题，还要感谢微软工程师浩然兄的提醒。
前言：
订阅与发布异构（我定义的名字）：实际指发布端和订阅端存在列长度上的不一致情况，如发布端某列为int类型，由于业务增长，需要扩容到bigint；
尽管replication支持DDL的传递，但直接在发布表上alter table，执行时间受表大小和更新频率影响较大，长时间的锁表必然是业务所不能容忍的；因此，想到个折中的办法——复制回路。
也就是通过一个闭环，本地发布的表创建一个到本地的异构订阅，在同步完数据后，通过交换表名的方式，实现数据表的alter变更操作，可以最大化的缩短锁表时间；
但这其中却碰到个问题，也就是本文要描述的中心内容；
闲话少叙，亮真家伙！
现象：创建异构表后，通过快照初始化时，发现订阅端记录全部乱掉；
1 CREATE TABLE test_a.dbo.tmp_byxl_01 (id INT NOT NULL PRIMARY KEY IDENTITY NOT FOR REPLICATION,flag TINYINT) 2 CREATE TABLE test_b.dbo.tmp_byxl_01_new (id BIGINT NOT NULL PRIMARY KEY IDENTITY NOT FOR REPLICATION ,flag TINYINT) 3 4 INSERT INTO test_a.dbo.tmp_byxl_01 VALUES(1),(2) 5 6 SELECT * FROM test_a.dbo.tmp_byxl_01 7 SELECT * FROM test_b.dbo.tmp_byxl_01