sql server mysql冲突_SQL SERVER 数据库中锁表冲突解决方案

并发处理是一件头痛的事情

事实上真的并发了,系统也不能处理,因为从原理来讲,数据库在做 Insert , Update ,Delete,Tran 的时候会锁住数据表

使用 Sp_who 就可以看到那些表被锁住,对象是什么.

所以,当你在往一个表中进行大量的事务操作时,另一个请求只能等待.相信有数据库编程经验的朋友都有体验.

但在实际的业务过程中,又有这样的情况出现,例如下面一个例子:

有一个多分点的库存系统,每个分点都连到同一台SQL Server数据库上.每天的工作都需要出库入库,并立刻得知库存数量.

但它的商品记录形式又特别奇怪,他不能用数字来代替,只能用记录来代替.

例如:

某东西有二个,你不能把这个东西用2这样的数字代替,而必须要使用二两记录来代替,因为记录中有这个东西的唯一标识,换句话说,你可以理解成它有几十万个产品项目,而每个产品项目的数量永远为1

对于它的出入库操作也是必须要记录这个唯一的标识号,并算它这个月出入库的次数,最后判断它是否存在仓库中.

对于这种特殊的需求,我们分析得知,它必须要实时的得到仓库库存,并要求校验

这是一个问题,它大大加重了数据库的使用率

最重要的是,若干个分点同时操作,一定会有并发冲突的问题.请看计算库存的方法:

每次计算库存,我都搜索上次盘存时间(盘存时间不固定).然后计算每一次入库单(有N种类型,不同的类型不同的表示,还有直接与出库相关的),出库单(N种类型),销售单

公式如下:

入库单 - 出库单 - 销售单 = 库存

这样,从分析上来讲,我们需要使用一个事务来套这个公式,并得出计算结果输出到一个表中.

公式的方法决定了效率.我们怎么实现这个公式呢?

一开始我们这样做:

从上次盘存开始的入库单相关明细插入库存表

删除从上次盘存以来的出库单相关明细信息(中间还有一些复杂的关系)

删除从上次盘存以来销售相关明细(中间有一些复杂的运算)

OK,得到了结果,速度也很快,几万条记录在3秒中之类就可以算完,可以交付客户使用

可是我们忘了最重要的事....(中间还碰到许多怪事)

事务会锁住库存表,如果并发操作,将会使计算时间变成30秒或更长(3秒突然变成30秒...是不是太长了点)

如果多个事务一起叠加,后果更为严重...导至重启SQL SERVER服务器都无效

(最后,不管有没有并发计算,都成为了至少二分钟才能算出来,而且重启服务器都无效...最后怎么解决的呢?是把数据库的日志文件删除,然后再附加才解决的...真是奇怪啊,怎么与日志文件有关...不懂SQL SERVER的日志文件还有这种作用)

这样的程序肯定不行,太不稳定了...拿回来再改

事实上,我们需要的是尽可能的缩小锁表的时间,达到减少并发冲突,而每个分点最然用一个表,但又被不同的分点ID区分了

上面的过程改一改

从上次盘存开始的入库单相关明细插入临时表(#tmpTable)

从临时表删除从上次盘存以来的出库单相关明细信息(中间还有一些复杂的关系)

从临时表删除从上次盘存以来销售相关明细(中间有一些复杂的运算)

把临时表的内容插入到库存表

这样,锁表的时间只有0.1表,基本上不会发生冲突,就算发生,也不会出现恶性的冲突叠加

基本上完成了工作,目前已经运行半年,运算速度良好

所以,处理并发的根本就是,减少锁表的操作,多用临时表,另外,临时表一定要加主键,如果不加主键,速度会慢10倍左右

冲突叠加是一个比较恐怖的事情,3秒钟的运算,冲突一次变30秒,再冲突一次变1:30,再冲突一次变3:00...

后来不冲突,也恒定在2:00分钟左右才能计算完毕,关于最后这样的结果,我实在想不通,最后还是通过去掉LOG才解决的问题

更让我郁闷

不知道各位高手是如何处理这种情况的.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值