让人闻风丧胆的 Mysql 锁机制
关注我,可了解更多有趣的面试相关问题。
本篇收录于《计算机核心知识串讲》
写在之前
前段时间,一位读者给我发私信,想让我分享一下 Mysql
中锁的机制。刚好最近自己也想总结这块,因此将分享一下锁在 Mysql
中的主要作用。
锁是计算机里控制多个线程并发情况下访问某一资源的机制,是保证线程安全的主要工具。在语言编程,锁有效保证线程执行安全性。在Mysql中锁同样有着举足轻重的作用。本文主要介绍锁机制,为你揭开 mysql
神秘的红头盖。
为什么需要锁?
为什么需要锁?
因为现在程序执行想要很快,导致多个程序来修改一个数据,多个人修改同一个数据,如果无法保证按照一定的规律、顺序来执行,则最终的数据肯定离自己想要的结果相距甚远。这种会产生并发引起的数据一致性就是 锁 需要解决的问题。
百花齐放 的 mysql 锁
首先看看 mysql
锁有哪些类型?
如果按照类型来划分主要可以分为:表锁、行锁
表锁又可以分为两种,读锁和写锁。那么两者有何区别呢?
表锁:针对同一份数据,多个读操作可以同时进行而不会互相影响(select)。比如 同一张 成绩单,张三看王二的成绩和李四看王二的成绩,两个人一起看会产生什么影响吗?
不会的。
所以说读锁可以与其他人共享的,又叫做 共享锁。
写锁:当前操作没完成之前,会阻塞其它读和写操作(update、insert、delete)
比如 张三想要修改自己的成绩,但是不允许李四、王二同时修改自己的分数。你说这种行为霸不霸道,肯定霸道的,这种又称为 排他锁。
可以发现这两种锁有很明显的缺点的,比如某个人如果修改自己的成绩,其他人连看不都可以看,这未免太霸道了。这种霸道就会带来各种问题。
比如:
需要对整张表加锁,虽然锁开销比较小(因为不会存在多个锁存在),加锁速度相应得也快,因为只有一个锁的原因,所以不可能导致死锁,但是存在致命的缺陷,效率低,可以同时容纳的线程并发性低。
表锁主要存在于 MyISAM
存储引擎中,其实我们再回顾一下 Java 中的锁机制中无论是synchronized
和 ReentrantLock
都是这种机制,都是一种排他类型的锁。
简单一句话总结:
读锁会阻塞写操作,不会阻塞读操作
写锁会阻塞读和写操作
倍受欢迎的行锁
正式由于表锁有致命的性能慢的缺点,所以推出了倍受欢迎的行锁,同时行锁分为两种:读锁和写锁。
所谓的读锁:允许一个事务去读一行,允许其他事务获取该行的读锁,但是不允许其他事务获得相同数据集的写锁。这种可以与读操作共享的锁,又称为共享锁(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中可以理解为线程)同时执行,效率比较高。
行锁的事务所带来的严重问题
更新丢失:
解决:让事务变成串行操作,而不是并发的操作,即对每个事务开始---对读取记录加排他锁脏读
解决:将事务隔离级别为Read uncommitted
不可重读
解决:使用Next-Key Lock
算法来避免幻读
解决:间隙锁(Gap Lock
)
总结
数据库的锁类型已经基本介绍完全了,锁主要可以划分为表锁和行锁,目前表锁使用的场景已经不多了,只有 一些 使用 MyISAM
存储引擎的数据库还在使用,目前主流还是以行锁为主。其实可以发现数据库中的锁和 Java 中的锁机制本质是相通的。
至于各自的优劣,与其他的技术一般,任何事物的带来都有其多面性,行锁带来了效率,同时带来了很多需要维护的问题(比如脏读、幻读等问题)。