文章目录
数据库中的锁
- 锁分类:
- 按锁的粒度划分:表级锁、行级锁、页级锁
- 按锁级别划分:共享锁、排它锁、意向锁
- 按加锁方式划分:自动锁、显示锁
- 按使用方式划分:乐观锁、悲观锁
1、从锁的粒度划分:表级锁、行级锁、页级锁来看
-
行级锁:行级锁分为共享锁和排他锁。行级锁是MySQL中锁定粒度最细的锁。行级锁开销大,加锁慢,锁定粒度最小,发生锁冲突的概率最低,并发度最高。
- MyISAM支持表级锁,InnoDB引擎支持行级锁和表级锁,只有在通过索引条件检索数据的时候,才使用行级锁,否就使用表级锁。
-
表级锁: 表级锁分为表共享(读)锁和表独占(写)锁。表级锁开销小,加锁快,锁定粒度大,发生锁冲突最高,并发度最低
-
页级锁: 页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快,但冲突多,行级冲突少,但速度慢。所以取了折中的页级,一次锁定相邻的一组记录。BDB支持页级锁。开销和加锁时间界于表锁和行锁之间;会出现死锁。锁定粒度界于表锁和行锁之间,并发度一般。
2、从锁类型划分:共享锁(读锁)、排它锁(写锁)、意向锁来看
-
共享锁(share lock):共享锁又叫读锁,如果事务T对A加上共享锁,则其他事务只能对A再加共享锁,不能加其他锁。共享锁的事务只能读数据,不能写数据。
-
排它锁(exclusive lock):排他锁又叫写锁,如果事务T对A加上排它锁,则其他事务都不能对A加任何类型的锁。获准排它锁的事务既能读数据,又能写数据
-
意向锁:
-
其实有排它锁和共享锁就足够了为什么还需要有意向锁,这里举一个比较形象的例子:
在mysql中有表级锁,读锁锁表,会阻塞其他事务修改表数据。写锁锁表,会阻塞其他事务读和写。
- Innodb引擎又支持行锁,行锁分为共享锁,一个事务对一行的共享只读锁。排它锁,一个事务对一行的排他读写锁。
- 这两中类型的锁共存的问题考虑这个例子:事务A锁住了表中的一行,让这一行只能读,不能写。之后,事务B申请整个表的写锁。如果事务B申请成功,那么理论上它就能修改表中的任意一行,这与A持有的行锁是冲突的。数据库需要避免这种冲突,就是说要让B的申请被阻塞,直到A释放了行锁。
-
数据库要怎么判断这个冲突呢?
- step1:判断表是否已被其他事务用表锁锁表
- step2:判断表中的每一行是否已被行锁锁住。
(注意step2,这样的判断方法效率实在不高,因为需要遍历整个表。于是就有了意向锁。在意向锁存在的情况下,事务A必须先申请表的意向共享锁,成功后再申请一行的行锁。)
-
在意向锁存在的情况下,上面的判断可以改成
- step1:不变
- step2:发现表上有意向共享锁,说明表中有些行被共享行锁锁住了,因此,事务B申请表的写锁会被阻塞。
(注意:申请意向锁的动作是数据库完成的,就是说,事务A申请一行的行锁的时候,数据库会自动先开始申请表的意向锁,不需要我们程序员使用代码来申请。)
-
3、从加锁方式划分:自动锁、显示锁来看
-
自动锁:存储引擎例如InnoDB的,MyISAM,都会自动给数据加锁,不需要用户参与,大体上都是在执行查询语句(SELECT)前,会自动给涉及的所有数据集(表,MyISAM只有表级锁)加读锁,在执行更新操作(UPDATE、DELETE、INSERT等)前,会自动给涉及的数据集(表)加写锁,
-
显示锁:显示加锁就是在手写sql语句时,加上锁的语句,例如
-
MyISAM中:
SELECT SUM(total) FROM orders; SELECT SUM(subtotal) FROM order_detail; //加锁之后 LOCK tables orders read local,order_detail read local; SELECT SUM(total) FROM orders; SELECT SUM(subtotal) FROM order_detail; Unlock tables;
-
InnoDB中:
共享锁(读锁):SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE 排他锁(写锁):SELECT * FROM table_name WHERE ... FOR UPDATE
-
4、使用方式划分:乐观锁、悲观锁(写锁)来看
-
悲观锁(悲观并发控制):就是对数据的冲突采取一种悲观的态度,也就是说假设数据肯定会冲突,所以在数据开始读取的时候就把数据锁定住。【数据锁定:数据将暂时不会得到修改】
-
乐观锁(乐观并发控制):认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则让用户返回错误的信息。让用户决定如何去做。
-
并发控制的主要采用的技术手段:乐观锁、悲观锁和时间戳。
理解
- 乐观锁是一种思想,具体实现是,表中有一个版本字段,第一次读的时候,获取到这个字段。处理完业务逻辑开始更新的时候,需要再次查看该字段的值是否和第一次的一样。如果一样更新,反之拒绝。之所以叫乐观,因为这个模式没有从数据库加锁。
- 乐观锁,优点程序实现,不会存在死锁等问题。他的适用场景也相对乐观。阻止不了除了程序之外的数据库操作。
- 悲观锁是读取的时候为后面的更新加锁,之后再来的读操作都会等待。这种是数据库锁
- 悲观锁是数据库实现,他阻止一切数据库操作。
实现
-
悲观锁:
-
排它锁,当事务在操作数据时把这部分数据进行锁定,直到操作完毕后再解锁,其他事务操作才可操作该部分数据。这将防止其他进程读取或修改表中的数据。
-
实现:大多数情况下依靠数据库的锁机制实现
一般使用 select …for update 对所选择的数据进行加锁处理,例如select * from account where name=”Max” for update, 这条sql 语句锁定了account 表中所有符合检索条件(name=”Max”)的记录。本次事务提交之前(事务提交时会释放事务过程中的锁),外界无法修改这些记录。
-
-
乐观锁:
-
如果有人在你之前更新了,你的更新应当是被拒绝的,可以让用户重新操作。
-
实现:大多数基于数据版本(Version)记录机制实现
具体可通过给表加一个版本号或时间戳字段实现,当读取数据时,将version字段的值一同读出,数据每更新一次,对此version值加一。当我们提交更新的时候,判断当前版本信息与第一次取出来的版本值大小,如果数据库表当前版本号与第一次取出来的version值相等,则予以更新,否则认为是过期数据,拒绝更新,让用户重新操作。
-
5、数据库存储引擎中的锁
5.1、MyISAM的锁
-
在使用MyIsam时,我们只可以使用表级锁,而MySQL的表级锁有两种模式:
表共享读锁(Table Read Lock)和表独占写锁(Table Write Lock),他们在工作时表现如下:
- 对某一个表的读操作,不会阻塞其他用户对同一表请求,但会阻塞对同一表的写请求;
- 对MyISAM的写操作,则会阻塞其他用户对同一表的读和写操作;
- MyISAM表的读操作和写操作之间,以及写操作之间是串行的。
当一个线程获得对一个表的写锁后,只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待,直到锁被释放为止。
5.2、InnoDB的锁
-
InnoDB引擎支持行级锁和表级锁,只有在通过索引条件检索数据的时候,才使用行级锁,否就使用表级锁。
-
InnoDB实现了以下两种类型的行锁。
-
共享锁(读锁,S):允许一个事务去读一行,阻止其他事务对该数据进行修改。
-
排他锁(写锁,X):允许获取排他锁的事务更新数据,阻止其他事务对数据进行查询或者修改。
-
另外,行锁虽然很赞,但是还有一个问题,如果一个事务对一张表的某条数据进行加锁,这个时候如果有另外一个线程想要用LOCK TABLES进行锁表,这时候数据库要怎么知道哪张表的哪条数据被加了锁,一张张表一条条数据去遍历是不可行的。InnoDB考虑到这种情况,设计出另外一组锁:意向共享锁(IS)和意向排他锁(IX)。 目的也是为了允许行锁和表锁共存,实现多粒度锁机制,这两种意向锁都是表锁同时也是InnoDB内部使用的意向锁(Intention Locks)。
- 意向共享锁(IS):当一个事务要给一条数据加S锁的时候,会先对数据所在的表先加上IS锁,成功后才能加上S锁。
- 意向排他锁(IX):当一个事务要给一条数据加X锁的时候,会先对数据所在的表先加上IX锁,成功后才能加上X锁。
- 意向锁之间兼容,不会阻塞。但是会跟S锁和X锁冲突,冲突的方式跟读写锁相同。例如当一张表上已经有一个排它锁(X锁),此时如果另外一个线程要对该表加意向锁,不管意向共享锁还是意向排他锁都不会成功。
-
-
当前锁模式/是否兼容/请求锁模式 排他锁 意向排他锁 共享锁 意向共享锁 排他锁 冲突 冲突 冲突 冲突 意向排他锁 冲突 兼容 冲突 兼容 共享锁 冲突 冲突 兼容 兼容 意向共享锁 冲突 兼容 兼容 兼容 如果一个事务请求的锁模式与当前的锁兼容,InnoDB就请求的锁授予该事务;反之,如果两者两者不兼容,该事务就要等待锁释放。
-
意向锁是InnoDB自动加的,不需用户干预。对于UPDATE、DELETE和INSERT语句,InnoDB会自动给涉及的数据集加排他锁(X);对于普通SELECT语句,InnoDB会自动给涉及数据集加共享锁(S);事务可以通过以下语句显式给记录集加共享锁或排锁。
共享锁(S):SELECT * FROM table_name WHERE … LOCK IN SHARE MODE
排他锁(X):SELECT * FROM table_name WHERE … FOR UPDATE
用SELECT … IN SHARE MODE获得共享锁,主要用在需要数据依存关系时确认某行记录是否存在,并确保没有人对这个记录进行UPDATE或者DELETE操作。但是如果当前事务也需要对该记录进行更新操作,则很有可能造成死锁,对于锁定行记录后需要进行更新操作的应用,应该使用SELECT … FOR UPDATE方式获取排他锁。