MySQL并发更新数据时的处理方法

前言

在后端开发中咱们不可避免的会碰见MySQL数据并发更新的状况，做为一名后端研发，如何解决这类问题也是必需要知道的，同时这也是面试中常常考察的知识点。

UPDATE是否会加锁？

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种：

• 经过事务显式的对SELECT进行加锁
• 使用乐观锁机制

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操做。（从新查询记数据行，再次使用新的版本号更新数据）

实践

对 for update上锁进行一次实践

一个student表，其中有一条数据

开启两个client

第一个开启事务后执行

select name from student where id = 1 for update;复制代码

第二个开启事务后执行相同的语句，发现该条数据被第一个事务上锁阻塞了

这时候第一个事务执行修改并commit；

第二个事务的select执行，发现阻塞了4秒多

小结

总的来讲，这2种方式均可以支持数据库的并发更新操做。但具体使用哪种就得看实际的应用场景，应用场景对哪一种支持更好，而且对性能的影响最小。

参考自：

chenguangwu.github.io/evernode/My…