mysql的封锁机制以及读锁和写锁的区别
转载自 :https://blog.csdn.net/youcijibi/article/details/78142767
我们在开发中也许都有感受到,数据库的并发操作会带来许多问题,比如丢失更新、不可重复读、读脏数据(幽灵数据)等等,常见的比如自动售票系统,站点1、2同时读出剩余的票数n张,站点1售出一张票,并将n-1写入数据库,站点2也售出一张票并将n-1写入数据库,但是我们都知道,应剩余n-2张票,这就是典型的丢失数据更新的实例。为避免该类问题的产生,我们采用了封锁机制,简单点就是当一个线程要对数据库进行相关操作时,先给数据库加上适当的锁,以此来避免其他线程对数据库进行操作而带来的干扰。
并发操作之所以产生错误,是因为不同线程并发执行事务互相干扰造成的。所以我们要对事务的并发操作进行控制,即并发控制。一般DBMS进行并发控制的方法是封锁机制和事务机制。
封锁就是对数据表、数据行等操作之前,先向系统请求对其加锁,说通俗点就是操作之前先声明权限。
封锁的周期(环节):申请加锁、获得锁权限、释放锁权限
最基本的封锁类型有两种:排它锁(Exclusive Locks,X锁)和共享锁(Share Locks,S锁)。
-
排它锁也称独占锁、写锁或X锁,若sessionA获得某数据表的排他锁权限,那么sessionA只能对该表进行读取或修改,其他session既不能读取也不能修改该表,更不能对该表加任何类型的锁,直到sessionA释放排它锁权限。加锁方式:lock tables tablename write;操作如下:
sessionA:
sessionB:
从上图操作可以看出sessionA获得ha表排它锁权限以后sessionB执行访问ha表操作以后并没用显示ha数据而是在等待sessionA释放锁权限。 -
共享锁也称读锁或S锁,若sessionA获得某数据表的共享锁权限,那么任何session(包括sessionA)只能对该表进行读取,不能修改该表,sessionA可以继续对该数据表加X锁,其他session可以对该数据表继续加S锁但不能加X锁,直到sessionA释放共享锁权限。加锁方式:set tables tablename read;操作如下:
sessionA:
sessionB:
从上图操作可以看出,sessionA获得ha表共享锁权限以后,sessionA和sessionB都可以访问ha表,但是当sessionA想更改ha表时直接报错(ERROR 1099 (HY000): Table ‘ha’ was locked with a READ lock and can’t be updated ha表有一个共享锁不能被修改),sessionB更改ha表时并没有显示修改成功,而是在等待sessionA释放共享锁权限。 -
注意,在sessionA同时获得某数据表的S和X锁权限时,sessionA只能select该数据表,其他session将不能对该表进行任何操作,包括select、update、drop、delete、lock等等,直到sessionA释放相关锁权限。
表锁的加锁/解锁方式
MyISAM 在执行查询语句(SELECT
)前,会自动给涉及的所有表加读锁,在执行更新操作 (UPDATE
、DELETE
、INSERT
等)前,会自动给涉及的表加写锁,这个过程并不需要用户干预,因此,用户一般不需要直接用LOCK
TABLE
命令给MyISAM表显式加锁。
如果用户想要显示的加锁可以使用以下命令:
- 锁定表:LOCK TABLES tbl_name {READ | WRITE},[ tbl_name {READ | WRITE},…]
-
- 解锁表:UNLOCK TABLES
- 1
- 2
- 3
在用
LOCK TABLES
给表显式加表锁时,必须同时取得所有涉及到表的锁。在执行
LOCK TABLES
后,只能访问显式加锁的这些表,不能访问未加锁的表;如果加的是读锁,那么只能执行查询操作,而不能执行更新操作。
在自动加锁的情况下也基本如此,MyISAM 总是一次获得 SQL 语句所需要的全部锁。这也正是 MyISAM 表不会出现死锁(Deadlock Free)的原因。