SQLServer并发问题,先SELECT后UPDATE,避免并发脏读情况解决

在SQL Server中,需要对数据操作进行先SELECT 之后UPDATE,对于这样的操作,如果出现高并发,可能导致脏读情况的发生。不能保证数据的同步。

解决方案是在事物中对表进行加更新锁:

事务一:

begin tran
declare @count int =0
select @count=[Count] from tb_name WITH(UPDLOCK,HOLDLOCK) where id=1
select @count as count1
waitfor delay ‘00:00:30‘
update tb_name set [Count]=@count+1 where id=1
commit tran 

select * from tb_name

事务二:

begin tran
declare @count int =0
select @count=[Count] from tb_name WITH(UPDLOCK,HOLDLOCK) where  id=1
select @count as count2
update tb_name set [Count]=@count+1 where id=1
commit tran 

select * from tb_name
时间: 2024-11-12 14:35:08

SQLServer并发问题,先SELECT后UPDATE,避免并发脏读情况解决的相关文章

sql server中高并发情况下 同时执行select和update语句死锁问题 (一)

 最近在项目上线使用过程中使用SqlServer的时候发现在高并发情况下,频繁更新和频繁查询引发死锁.通常我们知道如果两个事务同时对一个表进行插入或修改数据,会发生在请求对表的X锁时,已经被对方持有了.由于得不到锁,后面的Commit无法执行,这样双方开始死锁.但是select语句和update语句同时执行,怎么会发生死锁呢?看完下面的分析,你会明白的- 首先看到代码中使用的查询的方法Select <span style="font-size:18px;"> /// &

MySQL中SELECT+UPDATE处理并发更新问题解决方案

这篇文章主要介绍了MySQL中SELECT+UPDATE处理并发更新问题解决方案分享,需要的朋友可以参考下. 问题背景 假设MySQL数据库有一张会员表vip_member(InnoDB表),结构如下: 当一个会员想续买会员(只能续买1个月.3个月或6个月)时,必须满足以下业务要求: 如果end_at早于当前时间,则设置start_at为当前时间,end_at为当前时间加上续买的月数 如果end_at等于或晚于当前时间,则设置end_at=end_at+续买的月数 续买后active_statu

Mysql加锁过程详解(4)-select for update/lock in share mode 对事务并发性影响

select for update/lock in share mode 对事务并发性影响 事务并发性理解 事务并发性,粗略的理解就是单位时间内能够执行的事务数量,常见的单位是 TPS( transactions per second). 那在数据量和业务操作量一定的情况下,常见的提高事务并发性主要考虑的有哪几点呢? 1.提高服务器的处理能力,让事务的处理时间变短. 这样不仅加快了这个事务的执行时间,也降低了其他等待该事务执行的事务执行时间. 2.尽量将事务涉及到的 sql 操作语句控制在合理范

select..for update

select..for update; 给数据库表手动上锁 这条语句会开启一个session,直到这个session Commit,其他session才能执行更新.插入.删除操作,对查询没有影响,但是这张表再不能开启其他select..for update; 使用情况:使用count(*)作为流水号字段的值时,在高并发情况下容易出现重复,此时用select..for update;执行插入前锁住这张表来保证流水号不重复,使用时把select..for update;与执行insert.updat

MySQL的SELECT ...for update

最近的项目中,因为涉及到Mysql数据中乐观锁和悲观锁的使用,所以结合项目和网上的知识点对乐观锁和悲观锁的知识进行总结. 悲观锁介绍 悲观锁是对数据被的修改持悲观态度(认为数据在被修改的时候一定会存在并发问题),因此在整个数据处理过程中将数据锁定.悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在应用层中实现了加锁机制,也无法保证外部系统不会修改数据). 使用场景举例 商品goods表中有一个字段status,status为1代表商品未

Mysql查询语句使用select.. for update导致的数据库死锁分析

近期有一个业务需求,多台机器需要同时从Mysql一个表里查询数据并做后续业务逻辑,为了防止多台机器同时拿到一样的数据,每台机器需要在获取时锁住获取数据的数据段,保证多台机器不拿到相同的数据. 我们Mysql的存储引擎是innodb,支持行锁.解决同时拿数据的方法有很多,为了更加简单,不增加其他表和服务器的情况下,我们考虑采用select... for update的方式,这样X锁锁住查询的数据段,表里其他数据没有锁,其他业务逻辑还是可以操作. 这样一台服务器比如select .. for upd

【转载】MySQL事务以及SELECT ... FOR UPDATE的使用

MySQL中的事务,默认是自动提交的,即autocommit = 1: 但是这样的话,在某些情形中就会出现问题:比如: 如果你想一次性插入了1000条数据,mysql会commit1000次的, 如果我们把autocommit关闭掉[autocommit = 0],通过程序来控制,只要一次commit就可以了,这样也才能更好的体现事务的特点! 对于需要操作数值,比如金额,个数等等! 记住一个原则:一锁二判三更新 如果SELECT 后面若要UPDATE 同一个表单,最好使用SELECT ... F

select for update行锁

select for update行锁 2008-05-26 15:15:37 分类: Oracle Select-For Update语句的语法与select语句相同,只是在select语句的后面加FOR UPDATE [NOWAIT]子句. 该语句用来锁定特定的行(如果有where子句,就是满足where条件的那些行).当这些行被锁定后,其他会话可以选择这些行,但不能更改或删除这些行,直到该语句的事务被commit语句或rollback语句结束为止. 如图20.51所示,左上角的会话用Sel

SELECT FOR UPDATE(转)

MySQL  使用SELECT ... FOR UPDATE 做事务写入前的确认 以MySQL 的InnoDB 为例,预设的Tansaction isolation level 为REPEATABLE READ,在SELECT 的读取锁定主要分为两种方式: SELECT ... LOCK IN SHARE MODE SELECT ... FOR UPDATE 这两种方式在事务(Transaction) 进行当中SELECT 到同一个数据表时,都必须等待其它事务数据被提交(Commit)后才会执行