下车扫描，业务部门一直反应慢，不稳定，程序不是报黄页就是运行慢，严重影响师傅使用，估计师傅心里一直"很想我们"。
第一次优化
和同事一起看了程序业务逻辑，觉得应该将整个扫描逻辑过程放到存储过程，一可以避免程序在交互中的影响，二可以提高性能。
修改完后，由于需要读取Sequence，在存储过程中需要运行下列命令
来获取：
SELECT @DeliveryItemStatusSysNo= dbo.CreateSequence('DeliveryItem_Status_Sequence',1,'192.168.2.8',6060)
第二次优化
扫描过程优化上线，没多久，周六上午同事说下车扫描还是有问题，运行很慢也不稳定，分析下来发现是取Sequence的问题。
由于取Sequence不能并发。只能通过预取Sequence好后，提供给存储过程执行。
修改成了：
select @DeliveryItemStatusSysNo= MIN(sysno)from DeliveryItem_Status_Sequence where useflag=0
update DeliveryItem_Status_Sequence set useflag=1 where sysno=@DeliveryItemStatusSysNo and useflag=0
第三次优化
优化后，心想这回取Sequence不会慢了，但是新问题又来了，由于这个下单扫描并发非常高，从凌晨到早上7点大约有6K单。
运行后发现这个Sequence取有重复的情况。一重复就报错。后来只能修改成：
将隔离级别修改成最高，这样就不会重复：
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN tran
select @DeliveryItemStatusSysNo= MIN(sysno)from DeliveryItem_Status_Sequence where useflag=0
update DeliveryItem_Status_Sequence set useflag=1 where sysno=@DeliveryItemStatusSysNo and useflag=0
COMMIT TRAN
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
第四次优化
经过三次优化应该没有问题了，但是运行下来，发现出现大量的死锁。由于隔离级别的提高，并发变成了顺序提交，死锁上来了。有没有
其他办法来解决并发和重复的问题，这个问题一直困扰我，查了一下SQL server的帮助文档。想起一个新的方法，修改sql如下：DECLARE @tbVarSysNo table(
SysNo INT
)
--更新状态表
UPDATE TOP (1) DeliveryItem_Status_Sequence
SET useflag=1
OUTPUT INSERTED.SysNo
INTO @tbVarSysNo WHERE useflag=0;
SELECT @DeliveryItemStatusSysNo=SysNo FROM @tbVarSysNo以上sql直接修改随机一条SysNO并取出，不需要去select和update成2次表，可以避免查询和更新的时间差引起重复和并发的情况
第五次优化
经过上面4次优化，观察发现不重复和并发的问题解决了，但是在更新MERGE INTO DeliveryItem_Status
表时，出现了死锁情况，经过跟踪这个死锁信息，发现是用了SERIALIZABLE隔离级别，检查程序和存储过程，
没有地方声明SERIALIZABLE隔离级别，估计是SQL Server的bug，没办法，只能手工在存储过程中声明成
READ COMMITTED隔离级别，，这一次修改后， 运行2天后发现，以上死锁，重复sysno和执行慢都解决了
这一次修改后，
总结
以上就是扫描的5次优化的全过程和解决方法，希望对大家后面的优化系统提供一些信息和参考。