vlambda博客
学习文章列表

让人闻风丧胆的 Mysql 锁机制

关注我,可了解更多有趣的面试相关问题。 
本篇收录于《计算机核心知识串讲》

写在之前

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

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

为什么需要锁?

为什么需要锁?

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

百花齐放 的 mysql 锁

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

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

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

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

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

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

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

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

简单一句话总结:

  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 中的锁机制本质是相通的。

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