关注我，可了解更多有趣的面试相关问题。
本篇收录于《offer快到碗里来》

写在之前

前段时间，一位读者给我发私信，想让我分享一下 Mysql 中锁的机制。刚好最近自己也想总结这块，因此将分享一下锁在 Mysql 中的主要作用。

锁是计算机里控制多个线程并发情况下访问某一资源的机制，是保证线程安全的主要工具。在语言编程，锁有效保证线程执行安全性。在Mysql中锁同样有着举足轻重的作用。本文主要介绍锁机制，为你揭开 mysql 神秘的红头盖。

为什么需要锁？

为什么需要锁？

因为现在程序执行想要很快，导致多个程序来修改一个数据，多个人修改同一个数据，如果无法保证按照一定的规律、顺序来执行，则最终的数据肯定离自己想要的结果相距甚远。这种会产生并发引起的数据一致性就是 锁 需要解决的问题。

百花齐放 的 mysql 锁

首先看看 mysql 锁有哪些类型？

如果按照类型来划分主要可以分为：表锁、行锁

表锁又可以分为两种，读锁和写锁。那么两者有何区别呢？

表锁：针对同一份数据，多个读操作可以同时进行而不会互相影响（select）。比如 同一张 成绩单，张三看王二的成绩和李四看王二的成绩，两个人一起看会产生什么影响吗？
不会的。
所以说读锁可以与其他人共享的，又叫做 共享锁。

写锁：当前操作没完成之前，会阻塞其它读和写操作（update、insert、delete）
比如 张三想要修改自己的成绩，但是不允许李四、王二同时修改自己的分数。你说这种行为霸不霸道，肯定霸道的，这种又称为 排他锁。

可以发现这两种锁有很明显的缺点的，比如某个人如果修改自己的成绩，其他人连看不都可以看，这未免太霸道了。这种霸道就会带来各种问题。

比如：
需要对整张表加锁，虽然锁开销比较小（因为不会存在多个锁存在），加锁速度相应得也快，因为只有一个锁的原因，所以不可能导致死锁，但是存在致命的缺陷，效率低，可以同时容纳的线程并发性低。

表锁主要存在于 MyISAM 存储引擎中，其实我们再回顾一下 Java 中的锁机制中无论是synchronized 和 ReentrantLock 都是这种机制，都是一种排他类型的锁。

简单一句话总结：

1. 读锁会阻塞写操作，不会阻塞读操作
2. 写锁会阻塞读和写操作

倍受欢迎的行锁

正式由于表锁有致命的性能慢的缺点，所以推出了倍受欢迎的行锁，同时行锁分为两种：读锁和写锁。

所谓的读锁：允许一个事务去读一行，允许其他事务获取该行的读锁，但是不允许其他事务获得相同数据集的写锁。这种可以与读操作共享的锁，又称为共享锁（shared lock）。

举一个前几年满大街的共享单车，同一个单车，你看的时候，可以阻止其他人看吗？不能阻止吧。你骑车的时候，允许骑他人也用吗？那肯定也不可以的。

写锁：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享锁和排他锁。这种比较霸道了，自己想要修改数据的时候，即不允许其他人修改，也不允许其他人看。这种也叫排他锁（exclusive lock）。

在这两种类型之上又衍生了两种类似于共享锁和排他锁的东西。
意向共享锁（intend shared lock）:一个事务给一个数据行加共享锁时，必须先获得表的意向共享锁。
意向排它锁（intend exclusive lock）:一个事务给一个数据行加排他锁时，必须先获得该表的IX锁。

共享锁和排他锁很好理解，但是意向锁如何理解呢？

举个例子：

事务A锁住了表中的一行，让这一行只能读，不能写。
之后，事务B申请整个表的写锁，也就是说只能写，其他事务既不能读也不能写。
如果事务B申请成功，那么理论上它就能修改表中的任意一行，这与A持有的行锁是冲突的。
数据库需要避免这种冲突，就是说要让B的申请被阻塞，直到A释放了行锁。

数据库要怎么判断这个冲突呢？

(1)：判断表是否已被其他事务用表锁锁表
(2)：判断表中的每一行是否已被行锁锁住。

注意第二步，这样的判断方法效率实在不高，因为需要遍历整个表。
于是就有了意向锁。

在意向锁存在的情况下，事务 A 必须先申请表的意向共享锁，成功后再申请一行的行锁。

在意向锁存在的情况下，上面的判断可以改成

(1)：不变
(2)：发现表上有 意向共享锁 ，说明表中有些行被共享行锁锁住了，因此，事务 B 申请表的写锁会被阻塞。

注意：申请意向锁的动作是数据库完成的，就是说，事务 A 申请一行的行锁的时候，数据库会自动先开始申请表的意向锁，不需要我们程序员使用代码来申请。

行锁默认的存储引擎主要有InnoDB。

从上面可以看出行锁的主要特点，只是对某一行加锁，多个行都有锁，需要维护锁之间的关系，锁开销比较大，加锁速度慢，同时会出现比较经典的问题死锁，那为什么还饱受欢迎呢？因为锁粒度小，导致并发性比较高，可以容忍多个事务（Java中可以理解为线程）同时执行，效率比较高。

行锁的事务所带来的严重问题

1. 更新丢失：
   解决：让事务变成串行操作，而不是并发的操作，即对每个事务开始---对读取记录加排他锁
2. 脏读
   解决：将事务隔离级别为 Read uncommitted
3. 不可重读
   解决：使用 Next-Key Lock 算法来避免
4. 幻读
   解决：间隙锁（Gap Lock）

总结

数据库的锁类型已经基本介绍完全了，锁主要可以划分为表锁和行锁，目前表锁使用的场景已经不多了，只有 一些 使用 MyISAM 存储引擎的数据库还在使用，目前主流还是以行锁为主。其实可以发现数据库中的锁和 Java 中的锁机制本质是想通的。

至于各自的优劣，与其他的技术一般，任何事物的带来都有其多面性，行锁带来了效率，同时带来了很多需要维护的问题（比如脏读、幻读等问题）。