MySQL数据库锁详解

目录

一、锁的分类

一、按照粒度分类

1、分类

2、代码操作

二、按照属性分类

1、共享锁

2、排他锁

3、代码操作

三、按照加锁方式分类

1、隐式的自动加锁

2、显示的加锁

四、按照算法分类

1、间隙锁

2、临键锁

3、记录锁

五、按照模式分类

1、悲观锁        

2、乐观锁

六、按照状态分类

1、意向锁的解释

1、意向共享锁

2、意向排它锁

二、锁的监控

一、相关变量

二、系统的表信息

三、死锁

一、如何处理死锁

二、如何避免死锁


一、锁的分类

MySQL数据库锁详解_第1张图片

一、按照粒度分类

1、分类

  1. 全局锁:锁定数据库中的所有表。
  2. 表级锁:每次操作锁住整张表。
  3. 行锁:每次操作锁住对应的行数据。

2、代码操作

-- 全局锁的加锁和释放

FLUSH TABLES WITH READ LOCK;

unlock tables;


-- 表级锁的加锁和释放

lock tables 表名 read/write;

unlock tables;

-- 行锁

二、按照属性分类

1、共享锁

        共享锁,又称之为读锁,简称S锁,共享锁就是多个事务对于同一数据可以共享一把锁,都能访问到数据,但是只能读不能修改。只有当数据上的读锁被释放后,其他事务才能对其添加写锁。共享锁主要是为了支持并发的读取数据而出现的,读取数据时,不允许其他事务对当前数据进行修改操作,从而避免”不可重读”的问题的出现。

注意:

  1. 在不通过索引条件查询的时候,InnoDB使用的是表锁,而不是行锁。
  2. 由于MySQL的行锁是针对索引加的锁,不是针对记录加的锁,所以即使是访问不同行的记录,如果使用了相同的索引键,也是会出现锁冲突的。
  3. 当表有多个索引的时候,不同的事务可以使用不同的索引锁定不同的行,另外,不论是使用主键索引、唯一索引或普通索引,InnoDB都会使用行锁来对数据加锁。
  4. 即便在条件中使用了索引字段,但具体是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的,如果MySQL认为全表扫描效率更高,比如对一些很小的表,它就不会使用索引,这种情况下InnoDB将使用表锁,而不是行锁。因此,在分析锁冲突时,别忘了检查SQL的执行计划,以确认是否真正使用了索引。

2、排他锁

        排它锁,又称之为写锁、独占锁,简称X锁,当事务对数据加上写锁后,其他事务既不能对该数据添加读锁,也不能对该数据添加写锁,写锁与其他锁都是互斥的。只有当前数据写锁被释放后,其他事务才能对其添加写锁或者是读锁。写锁主要是为了解决在修改数据时,不允许其他事务对当前数据进行修改和读取操作,从而可以有效避免”脏读”问题的产生。

注意:

  1. mysql InnoDB引擎默认的修改数据语句(update,delete,insert),都会自动给涉及到的数据加上排他锁,select语句默认不会加任何锁类型,如果加排他锁可以使用select ...for update语句。
  2. 加过排他锁的数据行在其他事务种是不能修改数据的,也不能通过for update和lock in share mode锁的方式查询数据,但可以直接通过select ...from...查询数据,因为普通查询没有任何锁机制。

3、代码操作

-- 在事务中使用共享锁
STAET TRANSACTION;
SELECT * FROM tb1 WHERE id = 123 LOCK IN SHARE MODE;

-- 在事务中使用排他锁
STAET TRANSACTION;
SELECT * FROM tb1 WHERE id = 123 FOR UPDATE;

三、按照加锁方式分类

1、隐式的自动加锁

  1. InnoDB自动加意向锁。
  2. 对于UPDATE、DELETE和INSERT语句,InnoDB会自动给涉及数据集加排他锁(X);
  3. 对于普通SELECT语句,InnoDB不会加任何锁;
     

2、显示的加锁

  1. 共享锁(S):SELECT * FROM table_name WHERE … LOCK IN SHARE MODE
  2. 排他锁(X) :SELECT * FROM table_name WHERE … FOR UPDATE

四、按照算法分类

1、间隙锁

        间隙锁基于非唯一索引,它锁定一段范围内的索引记录。使用间隙锁锁住的是一个区间,而不仅仅是这个区间中的每一条数据。

select * from goods where id between 1 and 10 for update;

        即所有在(1,10)区间内的记录行都会被锁住,所有id 为 2、3、4、5、6、7、8、9 的数据行的插入会被阻塞,但是 1 和 10 两条记录行并不会被锁住。

2、临键锁

        临键锁,是记录锁与间隙锁的组合,它的封锁范围,既包含索引记录,又包含索引区间,是一个左开右闭区间。临键锁的主要目的,也是为了避免幻读(Phantom Read)。如果把事务的隔离级别降级为RC,临键锁则也会失效。

        每个数据行上的非唯一索引列上都会存在一把临键锁,当某个事务持有该数据行的临键锁时,会锁住一段左开右闭区间的数据。需要强调的一点是,InnoDB 中行级锁是基于索引实现的,临键锁只与非唯一索引列有关,在唯一索引列(包括主键列)上不存在临键锁。

3、记录锁

        记录锁是封锁记录,记录锁也叫行锁,例如:

select *from goods where id=1 for update;

        它会在 id=1 的记录上加上记录锁,以阻止其他事务插入,更新,删除 id=1 这一行。


五、按照模式分类

1、悲观锁        

        悲观锁是基于一种悲观的态度类来防止一切数据冲突,它是以一种预防的姿态在修改数据之前把数据锁住,然后再对数据进行读写,在它释放锁之前任何人都不能对其数据进行操作,直到前面一个人把锁释放后下一个人数据加锁才可对数据进行加锁,然后才可以对数据进行操作,一般数据库本身锁的机制都是基于悲观锁的机制实现的。

特点:

        可以完全保证数据的独占性和正确性,因为每次请求都会先对数据进行加锁, 然后进行数据操作,最后再解锁,而加锁释放锁的过程会造成消耗,所以性能不高,还有增加产生死锁的风险。

  • 悲观锁的实现,往往依靠数据库提供的锁机制。在数据库中,悲观锁的流程如下:
  • 在对记录进行修改前,先尝试为该记录加上排他锁(exclusive locking)。
  • 如果加锁失败,说明该记录正在被修改,那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。
  • 如果成功加锁,那么就可以对记录做修改,事务完成后就会解锁了。
  • 其间如果有其他对该记录做修改或加排他锁的操作,都会等待我们解锁或直接抛出异常。

        拿比较常用的 MySql Innodb 引擎举例,来说明一下在 SQL 中如何使用悲观锁。要使用悲观锁,必须关闭 MySQL 数据库的自动提交属性。因为 MySQL 默认使用 autocommit 模式,也就是说,当执行一个更新操作后,MySQL 会立刻将结果进行提交。(sql语句:set autocommit=0)

以电商下单扣减库存的过程说明一下悲观锁的使用:

-- 0 开始事务
BEGIN;
-- 1 查询出商品库存信息
SELECT quantity FROM items WHERE id = 1 FOR UPDATE;
-- 2 修改商品库存为2
UPDATE items SET quantity = 2 WHERE id = 1;
-- 3 提交事务
COMMIT;

        以上,在对id = 1的记录修改前,先通过 for update 的方式进行加锁,然后再进行修改。这就是比较典型的悲观锁策略。

        如果以上修改库存的代码发生并发,同一时间只有一个线程可以开启事务并获得id=1的锁,其它的事务必须等本次事务提交之后才能执行。这样可以保证当前的数据不会被其它事务修改。

        上面提到,使用 select…for update 会把数据给锁住,不过需要注意一些锁的级别,MySQL InnoDB 默认行级锁。行级锁都是基于索引的,如果一条 SQL 语句用不到索引是不会使用行级锁的,会使用表级锁把整张表锁住,这点需要注意。

2、乐观锁

        乐观锁是相对悲观锁而言的,乐观锁假设数据一般情况不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果冲突,则返回给用户异常信息,让用户决定如何去做。乐观锁适用于读多写少的场景,这样可以提高程序的吞吐量。

        一般通过版本号机制实现乐观锁,在数据表中加上版本号字段 version,表示数据被修改的次数。当数据被修改时,这个字段值会加1。

举个简单的例子:假设帐户信息表中有一个 version 字段,当前值为 1 ,而当前帐户的余额( balance )为 100 。

  • 操作员 A 此时准备将其读出( version=1 ),并从其帐户余额中扣除 50( 100-50 );
  • 操作员 A 操作的过程中,操作员 B 也读入此用户信息( version=1 ),并从其帐户余额中扣除 20 ( 100-20 );
  • 操作员 A 完成修改工作,将数据版本号加1( version=2 ),连同帐户扣除后余额( balance=50 ),提交到数据库完成更新;
  • 操作员 B 完成了操作,也将版本号加1( version=2 )试图向数据库提交数据( balance=80 ),但此时比对数据库记录版本发现,操作员 B 提交的数据版本号为 2 ,数据库记录的当前版本也为 2 ,不满足 “提交版本必须大于记录当前版本才能执行更新“ 的乐观锁策略。

        因此,操作员 B 的提交被驳回。这样,就避免了操作员 B 用基于 version=1 的旧数据修改,最终造成覆盖操作员 A 操作结果的可能。


六、按照状态分类

1、意向锁的解释

        意向锁是指,未来的某个时刻,事务可能要加共享/排它锁了,先提前声明一个意向。由于意向锁仅仅表明意向,它其实是比较弱的锁,意向锁之间并不相互互斥,而是可以并行。

意向锁的存在价值在于在定位到特定的行所持有的锁之前,提供一种更粗粒度的锁,可以大大节约引擎对于锁的定位和处理的性能,因为在存储引擎内部,锁是由一块独立的数据结构维护的,锁的数量直接决定了内存的消耗和并发性能。例如,事务A对表t的某些行修改(DML通常会产生X锁),需要对t加上意向排它锁,在A事务完成之前,B事务来一个全表操作(alter table等),此时直接在表级别的意向排它锁就能告诉B需要等待(因为t上有意向锁),而不需要再去行级别判断。

1、意向共享锁

        意向共享锁(intention shared lock, IS),它预示着,事务有意向对表中的某些行加共享S锁。

select ... lock in share mode,要设置IS锁,事务要获得某些行的S锁,必须先获得表的IS锁。

2、意向排它锁

        意向排它锁(intention exclusive lock, IX),它预示着,事务有意向对表中的某些行加排它X锁。

        select ... for update,要设置IX锁,事务要获得某些行的X锁,必须先获得表的IX锁。

比如我们开启一个事务,对某条记录添加一个排他锁,此时表存在两把锁:表上的意向排它锁与 id 为 "11111111"的数据行上的排它锁。

-- 开启事务
START TRANSACTION;
SELECT * FROM account_tbl WHERE id = "11111111" FOR UPDATE;

        如果另外一个事务T2想要添加共享锁时,此时检测到其他事务持有表的意向排他锁,就可以得知该表必然持有该表中某些数据行的排他锁,那么T2对表的加锁请求就会被排斥(阻塞),而无需去检测表中的每一行数据是否存在排它锁。


二、锁的监控

一、相关变量

  1. innodb_row_lock开头的变量

二、系统的表信息

        MySQL把事务和锁的信息都记录在information_schema库中,其中一下三个表涉及到锁。

  1. INNODB_TRX
  2. INNODB_LOCKS
  3. INNODB_LOCK_WAITS

三、死锁

一、如何处理死锁

  1. 方式一:等待,直至超时,一个事务阻塞的时间超过innodb_lock_wait_timeout 时,就会回滚。
  2. 方式二:使用死锁检测进行死锁处理。

二、如何避免死锁

  1. 合理设计索引,使业务SQL 尽可能通过索引定位更少的行,减少锁竞争。
  2. 调整业务逻辑SQL执行顺序,避免 update/delete 长时间持有锁的 SQL在事务前面
  3. 避免大事务,尽量将大事务拆成多个小事务来处理,小事务缩短锁定资源的时间,发生锁冲突的几率也更小。
  4. 在并发比较高的系统中,不要显式加锁,特别是是在事务里显式加锁。如 select ...for update 语句,如果是在事务里运行了start transaction 或设置了autocommit 等于0,那么就会锁定所查找到的记录
  5. 降低隔离级别调低也是较好的选择,比如将隔离级别从RR调整为RC,可以避免降低隔离级别。如果业务允许,可以避免掉很多因为gap锁造成的死锁。

你可能感兴趣的:(MySQL数据库,开发语言,mysql,数据库,sql)