MySQL锁的那些事

MySQL锁的那些事

前言

每当我们在翻看公司的面经时,总是会出现与锁有关的问题 , 那么这篇文章将为你彻底解决MySQL中那些与锁有关的事情

废话不多说先上图

这里是引用

锁的认识

  • 锁的解释

      计算机协调多个进程或线程并发访问某一资源的机制。
    
  • 锁的重要性

     在数据库中,除传统计算资源(CPU、RAM、I\O等)的争抢,数据也是一种供多用户共享的资源。如何保证数据并发访问的一致性,有效性,是所有数据库必须要解决的问题。
     锁冲突也是影响数据库并发访问性能的一个重要因素,因此锁对数据库尤其重要。
    
  • 锁的缺点

     加锁是消耗资源的,锁的各种操作,包括获得锁、检测锁是否已解除、释放锁等 ,都会增加系统的开销。
    
  • 简单的例子

     现如今网购已经特别普遍了,比如淘宝双十一活动,当天的人流量是千万及亿级别的,但商家的库存是有限的。系统为了保证商家的商品库
     存不发生超卖现象,会对商品的库存进行锁控制。当有用户正在下单某款商品最后一件时,系统会立马对该件商品进行锁定,防止其他用户
     也重复下单,直到支付动作完成才会释放(支付成功则立即减库存售罄,支付失败则立即释放)。
    

锁的类型

表锁

种类

  • 读锁(read lock),也叫共享锁(·shared lock)
    针对同一份数据,多个读操作可以同时进行而不会互相影响(select)
  • 写锁(write lock),也叫排他锁(exclusive lock)
    当前操作没完成之前,会阻塞其它读和写操作(update、insert、delete)
    默认加表锁的存储引擎
    MyISAM

特点

  • 对整张表加锁
  • 开销小
  • 加锁快
  • 无死锁
  • 锁粒度大,发生锁冲突概率大,并发性低

结论

  • 读锁会阻塞写操作,不会阻塞读操作
  • 写锁会阻塞读和写操作

建议

  • MyISAM的读写锁调度写优先,这也是MyISAM不适合做写为主表的引擎,因为写锁以后,其它线程不能做任何操作,大量的更新使查询很难得到锁,从而造成永远阻塞。

行锁

种类

  • 读锁(read lock),也叫共享锁(shared lock)
    允许一个事务去读一行,阻止其他事务获得相同数据集的排他锁
  • 写锁(write lock),也叫排他锁(exclusive lock)
    允许获得排他锁的事务更新数据,阻止其他事务取得相同数据集的共享锁和排他锁
  • 意向共享锁(IS)
    一个事务给一个数据行加共享锁时,必须先获得表的IS锁
  • 意向排它锁(IX)
    一个事务给一个数据行加排他锁时,必须先获得该表的IX锁

默认使用行级锁的存储引擎
InnoDB
特点

  • 对一行数据加锁
  • 开销大
  • 加锁慢
  • 会出现死锁
  • 锁粒度小,发生锁冲突概率最低,并发性高

事务并发带来的问题

  • 更新丢失
    解决:让事务变成串行操作,而不是并发的操作,即对每个事务开始—对读取记录加排他锁
  • 脏读
    解决:隔离级别为Read uncommitted
  • 不可重读
    解决:使用Next-Key Lock算法来避免
  • 幻读
    解决:间隙锁(Gap Lock)

页锁

  • 开销、加锁时间和锁粒度介于表锁和行锁之间,会出现死锁,并发处理能力一般(此锁不做多介绍)

如何上锁

*表锁

隐式上锁(默认,自动加锁自动释放

  • select //上读锁
  • insert、update、delete //上写锁

显式上锁

  • lock table tableName read;//读锁
    lock table tableName write;//写锁

解锁

  • unlock tables;//所有锁表

在这里插入图片描述

行锁
隐式加锁

  • select //不会上锁
  • insert、update、delete //上写锁
    select * from tableName lock in share mode;//读锁
    select * from tableName for update;//写锁

解锁

  • 提交事务(commit)
  • 回滚事务(rollback)
  • kill 阻塞进程

在这里插入图片描述
为什么上了写锁,别的事务还可以读操作? 因为InnoDB有MVCC机制(多版本并发控制),可以使用快照读,而不会被阻塞。

行锁的实现方式

4.1 Record Lock 锁

  • 单个行记录上的锁
    Record Lock总是会去锁住索引记录,如果InnoDB存储引擎表建立的时候没有设置任何一个索引,这时InnoDB存储引擎会使用隐式的主键来进行锁定

Gap Lock 锁

  • 当我们用范围条件而不是相等条件检索数据,并请求共享或排他锁时,InnoDB会给符合条件的已有数据记录的索引加锁,对于键值在条件范围内但并不存在的记录。

    优点:解决了事务并发的幻读问题
    不足:因为query执行过程中通过范围查找的话,他会锁定争个范围内所有 的索引键值,即使这个键值并不存在。
    间隙锁有一个致命的弱点,就是当锁定一个范围键值之后,即使某些不存在的键值也会被无辜的锁定,而造成锁定的时候无法插入锁定键值范围内任何数据。在某些场景下这可能会对性能造成很大的危害。

Next-key Lock 锁

  • 同时锁住数据+间隙锁
    在Repeatable Read隔离级别下,Next-key Lock 算法是默认的行记录锁定算法。

行锁的注意点

  • 只有通过索引条件检索数据时,InnoDB才会使用行级锁,否则会使用表级锁(索引失效,行锁变表锁)
  • 即使是访问不同行的记录,如果使用的是相同的索引键,会发生锁冲突
  • 如果数据表建有多个索引时,可以通过不同的索引锁定不同的行

优化建议

  1. 尽可能让所有数据检索都通过索引来完成,避免无索引行锁升级为表锁
  2. 合理设计索引,尽量缩小锁的范围
  3. 尽可能较少检索条件,避免间隙锁
  4. 尽量控制事务大小,减少锁定资源量和时间长度
  5. 尽可能低级别事务隔离

死锁

定义

  • 指两个或者多个事务在同一资源上相互占用,并请求锁定对方占用的资源,从而导致恶性循环的现象

产生的条件

  1. 查看死锁:show engine innodb status \G
  2. 自动检测机制,超时自动回滚代价较小的事务(innodb_lock_wait_timeout 默认50s)
  3. 人为解决,kill阻塞进程(show processlist)
  4. wait for graph 等待图(主动检测)

解决方案
5. 查看死锁:show engine innodb status \G
6. 自动检测机制,超时自动回滚代价较小的事务(innodb_lock_wait_timeout 默认50s)
7. 人为解决,kill阻塞进程(show processlist)
8. wait for graph 等待图(主动检测)

避免方式

  • 加锁顺序一致,尽可能一次性锁定所需的数据行
  • 尽量基于primary(主键)或unique key更新数据
  • 单次操作数据量不宜过多,涉及表尽量少
  • 减少表上索引,减少锁定资源
  • 尽量使用较低的隔离级别
  • 尽量使用相同条件访问数据,这样可以避免间隙锁对并发的插入影响
  • 精心设计索引,尽量使用索引访问数据
  • 借助相关工具:pt-deadlock-logger

乐观锁与悲观锁

在这里插入图片描述

悲观锁

解释

  • 假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作

实现机制

  • 表锁、行锁等

实现层面

  • 数据库本身

使用场景

  • 并发量大

乐观锁

解释

  • 假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性

实现机制

  • 提交更新时检查版本号或者时间戳是否符合

使用场景

  • 并发量小
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值