MySQL并发更新数据加锁处理

前阵子一个项目中涉及到了对MySQL数据的并发更新,对于同一个数据记录,使用了并发工具进行测试,结果数据被改乱了。原因是没有对MySQL的数据行进行加锁。而当时我使用的SQL语句类似如下:

UPDATE table1 SET num = num + 1 WHERE id=1;  

而实际上了呢?MySQL是支持给数据行加锁(InnoDB)的,并且在UPDATE/DELETE等操作时确实会自动加上排它锁。只是并非只要有UPDATE关键字就会全程加锁,针对上面的MySQL语句而言,其实并不只是一条UPDATE语句,而应该类似于两条SQL语句(伪代码):

a = SELECT * FROM table1 WHERE id=1;  
UPDATE table1 SET num = a.num + 1 WHERE id=1;  

其中执行SELECT语句时没有加锁,只有在执行UPDATE时才进行加锁的。所以才会出现并发操作时的更新数据不一致。原因找到了,解决问题就不远了。而针对这类问题,解决的方法可以有2种:

  1. 通过事务显式的对SELECT进行加锁
  2. 使用乐观锁机制

SELECT显式加锁

对SELECT进行加锁的方式有两种,如下:

SELECT ... LOCK IN SHARE MODE       #共享锁,其它事务可读,不可更新  
SELECT ... FOR UPDATE       #排它锁,其它事务不可读写  

如果你不使用这2种语句,默认情况下SELECT语句是不会加锁的。并且对于上面提到的场景,必须使用排它锁。另外,上面的2种语句只有在事务之中才能生效,否则不会生效。在MySQL命令行使用事务的方式如下

SET AUTOCOMMIT=0;   
BEGIN WORK;   
    a = SELECT num FROM table1 WHERE id=2 FOR UPDATE;    
    UPDATE table1 SET num = a.num + 1 WHERE id=2;   
COMMIT WORK;  
这样只要以后更新数据时,都使用这样事务来进行操作;那么在并发的情况下,后执行的事务就会被堵塞,直到当前事务执行完成。(通过锁把并发改成了顺序执行)

使用乐观锁

乐观锁是锁实现的一种机制,它总是会天真的认为所有需要修改的数据都不会冲突。所以在更新之前它不会给数据加锁,而只是查询了数据行的版本号(这里的版本号属于自定义的字段,需要在业务表的基础上额外增加一个字段,每当更新一次就会自增或者更新)。在具体更新数据的时候更新条件中会添加版本号信息,当版本号没有变化的时候说明该数据行未被更新过,并且也满足更新调教,所以会更新成功。当版本号有变化的时候,则无法更新数据行,因为条件不满足,此时就需要在进行一次SQL操作。(重新查询记数据行,再次使用新的版本号更新数据)

原则上,这2种方式都可以支持。具体使用哪一种就看实际的业务场景,对哪种支持更好,并且对性能的影响最小。

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值