MySQL锁，锁的到底是什么？

只要学计算机，「锁」永远是一个绕不过的话题。MySQL锁也是一样。

一句话解释MySQL锁：

MySQL锁是解决资源竞争的一种方案。

短短一句话却包含了3点值得我们注意的事情：

1. 对什么资源进行竞争？
2. 竞争的方式（或者说情形）有哪些？
3. 锁是如何解决竞争的？

这篇文章开始带你循序渐进地理解这几个问题。

 

《Java面试+学习》全家桶合集录

1. 资源的竞争方式

MySQL对资源的操作无非就是读、写两种方式，但是由于事务并发执行的存在，因此对同一资源的并发访问存在3种形式：

• 读—读：并发事务同时读取相同资源。由于读操作不会改变资源本身，因此这种情况下并不存在并发安全性问题。
• 读—写/写—读：一个事务对资源进行读操作，另一个事务对资源进行写操作。
• 写—写：并发事务同时对同一个资源进行写操作。

2. 读—写/写—读下的问题

假设一种情形，一个事务先对某个资源进行读操作，然后另一个事务再对该资源进行写操作，如果两个事务到此为止，必然不会导致并发问题。

可是事务这种东西，一般情况下就是包含有很多个子操作啊。

2.1. 幻读

想象一下啊，假设事务T1和T2并发执行，T1先查找了所有name为「王刚蛋」的用户信息，此时发现拥有这个硬汉名字的用户只有一个。然后T2插入了一个同样叫做「王刚蛋」的用户的信息，并且提交了。

 

 

2.2. 不可重复读

再来，同样是T1和T2两个事务，T1通过id = 1查询到了一条数据，然后T2紧接着UPDATE（DELETE也可以）了该条记录，不同的是，T2紧接着通过COMMIT提交了事务。

 

此时，T1再次执行相同的查询操作，会发现数据发生了变化，name字段由「王刚蛋」变成了「蝉沐风」。

如果一个事务读到了另一个已提交事务修改过的（或者是删除的）数据，而导致了前后两次读取的数据不一致的情况，这种事务并发问题叫做不可重复读。

2.3. 脏读

事情还没结束，假设T1和T2都要访问user_innodb表中id为1的数据，不同的是T1先读取数据，紧接着T2修改了数据的name字段，需要注意的是，T2并没有提交！

 

此时，T1再次执行相同的查询操作，会发现数据发生了变化，name字段由「王刚蛋」变成了「蝉沐风」。

如果一个事务读到了另一个未提交事务修改过的数据，而导致了前后两次读取的数据不一致的情况，这种事务并发问题叫做脏读。

2.4. 锁与MVCC的关系

总结一下：我们在读—写，写—读的情况下会遇到3种读不一致性的问题，脏读、不可重复读以及幻读。

那写—写呢？很显然，在不做任何措施的情况下，并发会出现更大的问题。那该怎么办呢？

一切的并发问题都可以通过串行化解决，但是串行化效率太低了！

再优化一下，一切并发问题都可以通过加锁来解决，这种方案我们称为基于锁的并发控制（Lock Bases Concurrency Control,