?
说明：
很多交易的系统都需要单据号，而单据号按顺序并发获取又是一件头疼的事！~
?
一般单据号格式为：前缀+日期+编号（如：KK20150501000001）
?
现在模拟测试，数据库中的单据号作为一张表处理。
数据库单据号表（Billnumber）存储每个账号及其最大的单据号总共一条记录
单据号是组合而成的字符串，后6位为序号。
?
获取单据号的存储过程：
EXEC [dbo].[GetBillnumber_Test]@Account='Account',@Billnumber NVARCHAR(20)OUTPUT
?
存储过程功能：传递用户账号，返回用户的最大单据号。
存储过程内部逻辑：（查询和更新都使用了聚集索引查找）
a. 表中找出该账号的单据号
b. 如果单据号存在，截取后位字符转数字加1生成新的单据号返回，并更新这条记录为最新单据号
c. 如果单据号不存在，则为这账号第一次插入新的单据号，并返回该单据号
?
但是并发操作时，就可能发生堵塞以及死锁。当前数据库的事务级别为读提交（read committed）。
通常的操作是，存储过程内部逻辑查询表中的单据号时（如上a.），加上锁并保持锁到事务结束。我这里为WITH(UPDLOCK,HOLDLOCK)，网上还有一种这样加法WITH (XLOCK,PAGLOCK) ，这种加锁方法会把整页数据都不能访问。
?
为了方便在SQLqueryStress测试，我把存储过程改为：
EXEC [dbo].[GetBillnumber_Test]@Account='Account'
?
即不返回单据号，而在存储过程末尾把单据号抛出，让SQLqueryStress能够获取查看单据号
DECLARE @RE NVARCHAR(100)
DECLARE @billNumber NVARCHAR(100)--已赋值的单据号（赋值过程不描述）
SET @RE=N'[billNumber='+@billNumber+N'] [SPID='+CONVERT(VARCHAR(10),@@SPID)+N']'
RAISERROR (@RE,16,1,@billNumber) --抛出
?
打开2个SQLQuerySrees窗口，设置好连接参数：
第一个窗口：打开1个连接，每个连接执行500次；账号为A
第二个窗口：打开1个连接，每个连接执行500次；账号为A
?
数据库中开启死锁跟踪：
-- 打开死锁跟踪
dbcc traceon(1222,-1)
dbcc tracestatus
?
【执行测试】
快速执行第一个,第二个SQLQuerySrees窗口（点击“GO”）
执行完成后，点击SQLQuerySrees日志查看：
?
测试结果：
发现单据号都是递增的，只是中间有跳跃，因为另一个进程也在获取单据号。查看SqlServer日志，并没有看到死锁！
打开几个SQLqueryStress测试也是一样。结果是正常和符合的！
?
?
但是！问题来了！~当数据库中创建了可更新订阅，并且在订阅数据库操作，就会产生死锁！~
?
对该表创建可更新订阅：
?
与上面一样，的步骤，对订阅数据库的单据表进行单据号的获取操作。
?
在执行SQLQuerySrees时，同时也快速返回到数据库，查看锁情况。参考脚本：SqlServer 查看当前锁请求情况的一个脚本
?
可以看到，一个spid在对表BillNumberRecord更新时，也触发将数据输入插入到同步队列表中。对单据表使用的是范围所RangeS_U和RangeX_X。这会儿查看SqlServer日志，
?
3个参与死锁的存储过程机器堵塞的语句：
sp_MSdel_dboBillNumberRecord：（死锁牺牲品） delete [dbo].[BillNumberRecord] where [Guid]=@pkc1and[Account] =@pkc2andmsrepl_tran_version=@msrepl_tran_version trg_MSsync_upd_BillNumberRecord： update [dbo].[BillNumberRecord]setmsrepl_tran_version=@c7 where [Guid] = @c1 and [Account] = @c2 EXEC[dbo].[GetBillnumberBySID_Test]：
操作为：更新单据表的单据号列为最大单据号（此处语句就不显示了）
?
资源列表如下：
-- deadlockvictim=processe988e0 resource-list keylock objectname= BillNumberRecordindexname=聚集索引id=locke1193c0mode=RangeX-X owner-list owner id=processcdac70mode=RangeX-X waiter-list waiter id= processe988e0mode=UrequestType=wait keylock objectname= BillNumberRecordindexname=主键(非聚集索引)id=lock58d986c0mode=U owner-list owner id= processe988e0mode=U waiter-list waiter id=processcdac70mode=UrequestType=wait
接下来在数据库中执行查看执行计划，到底处理了哪些语句：
EXEC [dbo].[GetBillnumber_Test]@Account='Account'
?
结果如下，按存储过程内部逻辑：
a. 首先查找这个账号当前的单据号（聚集索引查找）(UPDLOCK,HOLDLOCK)
?
b.单据号存在，生成一个新的最大单据号，更新回表中（聚集索引查找和更新）
?
c.扫描伪表inserted（聚集索引），在触发器trg_MSsync_upd_BillNumberRecord中
?
d. 扫描伪表deleted（聚集索引），在触发器trg_MSsync_upd_BillNumberRecord中
?
e. 触发器trg_MSsync_upd_BillNumberRecord执行更新msrepl_tran_version，（索引查找，更新聚集索引）
?
f.最后将同步的事务和命令插入到队列表中
?
上面能出现索引查找的，只有trg_MSsync_upd_BillNumberRecord了。使用主键非聚集索引（guid，account）查找，更新聚集索引（account）。
?
这算是设计上的问题，作为同步中的主键，最好也是聚集索引，表主键，在同步触发中是不会更改的，而同步是经常触发更改的，主键又不是聚集索引，将频繁地更改。但是现在数据已经同步中，不能更改了，只能使用其他方法。而没有同步的时候，并发是正常的，没出现死锁。就没要更改原来获取单据号的存储过程了，也没有什么可以改了。
?
既然是下面这个语句引起的，