电子文档交易市场
安卓APP | ios版本
电子文档交易市场
安卓APP | ios版本
换一换
首页 金锄头文库 > 资源分类 > DOCX文档下载
分享到微信 分享到微博 分享到QQ空间

面试必会系列之MySQL锁

  • 资源ID:217548573       资源大小:24.97KB        全文页数:10页
  • 资源格式: DOCX        下载积分:1金贝
快捷下载 游客一键下载
账号登录下载
微信登录下载
三方登录下载: 微信开放平台登录   支付宝登录   QQ登录  
二维码
微信扫一扫登录
下载资源需要1金贝
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
支付方式: 支付宝    微信支付   
验证码:   换一换

 
账号:
密码:
验证码:   换一换
  忘记密码?
    
1、金锄头文库是“C2C”交易模式,即卖家上传的文档直接由买家下载,本站只是中间服务平台,本站所有文档下载所得的收益全部归上传人(卖家)所有,作为网络服务商,若您的权利被侵害请及时联系右侧客服;
2、如你看到网页展示的文档有jinchutou.com水印,是因预览和防盗链等技术需要对部份页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有jinchutou.com水印标识,下载后原文更清晰;
3、所有的PPT和DOC文档都被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;下载前须认真查看,确认无误后再购买;
4、文档大部份都是可以预览的,金锄头文库作为内容存储提供商,无法对各卖家所售文档的真实性、完整性、准确性以及专业性等问题提供审核和保证,请慎重购买;
5、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据;
6、如果您还有什么不清楚的或需要我们协助,可以点击右侧栏的客服。
下载须知 | 常见问题汇总

面试必会系列之MySQL锁

面试必会系列之MySQL锁相关内容序言:文章内容适用于每一个学习后端编程的朋友详细总结了一下MySQL锁相关的知识,分享给大家MySQL的锁概述数据库锁定机制简单来说,就是数据库为了保证数据的一致性,而使各种共享资源在被并发访问变得有序所设计的一种规则。对于任何一种数据库来说都需要有相应的锁定机制,所以MySQL自然也不能例外。MySQL数据库由于其自身架构的特点,存在多种数据存储引擎,每种存储引擎所针对的应用场景特点都不太一样,为了满足各自特定应用场景的需求,每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计,所以各存储引擎的锁定机制也有较大区别。本文没有说明的情况下默认使用的是Innodb引擎。Innodb原理(简单说一下 innodb一定存在聚簇索引,默认以主键作为聚簇索引 有几个索引,就有几棵B+树(不考虑hash索引的情形) 聚簇索引的叶子节点为磁盘上的真实数据。非聚簇索引的叶子节点还是索引,指向聚簇索引B+树。 锁的分类 共享锁(S锁): 假设事务T1对数据A加上共享锁,那么事务T2可以读数据A,不能修改数据A。 排他锁(X锁): 假设事务T1对数据A加上排他锁,那么事务T2不能读数据A,不能修改数据A。我们通过update、delete等语句加上的锁都是行级别的锁。只有LOCK TABLE READ和LOCK TABLE WRITE才能申请表级别的锁。 意向共享锁(IS锁): 一个事务在获取(任何一行/或者全表)S锁之前,一定会先在所在的表上加IS锁。 意向排他锁(IX锁): 一个事务在获取(任何一行/或者全表)X锁之前,一定会先在所在的表上加IX锁。 意向锁存在的目的这里说一下意向锁存在的目的。假设事务T1,用X锁来锁住了表上的几条记录,那么此时表上存在IX锁,即意向排他锁。那么此时事务T2要进行LOCK TABLE WRITE的表级别锁的请求,可以直接根据意向锁是否存在而判断是否有锁冲突。加锁算法 Record Locks: 简单翻译为行锁。注意了,该锁是对索引记录进行加锁!锁是加在索引上而不是行上的。注意了,innodb一定存在聚簇索引,因此行锁最终都会落到聚簇索引上! Gap Locks: 简单翻译为间隙锁,是对索引的间隙加锁,其目的只有一个,防止其他事物插入数据。在Read Committed隔离级别下,不会使用间隙锁。这里我对官网补充一下,隔离级别比Read Committed低的情况下,也不会使用间隙锁,如隔离级别为Read Uncommited时,也不存在间隙锁。当隔离级别为Repeatable Read和Serializable时,就会存在间隙锁。 Next-Key Locks: 这个理解为Record Lock+索引前面的Gap Lock。记住了,锁住的是索引前面的间隙!比如一个索引包含值,10,11,13和20。那么,间隙锁的范围如下12345(negative infinity, 10(10, 11(11, 13(13, 20(20, positive infinity)还有不懂的地方可以看一下MySQL的官方文档快照读和当前读在mysql中select分为快照读和当前读,执行下面的语句select * from table where id = ?;执行的是快照读,读的是数据库记录的快照版本,是不加锁的。(这种说法在隔离级别为Serializable中不成立,后面会再补充。)那么,执行select * from table where id = ? lock in share mode;会对读取记录加S锁 (共享锁),执行select * from table where id = ? for update会对读取记录加X锁 (排他锁),那么加的是表锁还是行锁呢?表锁or行锁 针对这点,我们先回忆一下事务的四个隔离级别,他们由弱到强如下所示: Read Uncommited(RU): 读未提交,一个事务可以读到另一个事务未提交的数据! Read Committed (RC): 读已提交,一个事务可以读到另一个事务已提交的数据! Repeatable Read (RR): 可重复读,加入间隙锁,一定程度上避免了幻读的产生!注意了,只是一定程度上,并没有完全避免!另外就是记住从该级别才开始加入间隙锁(这句话记下来,后面有用到)! Serializable: 串行化,该级别下读写串行化,且所有的select语句后都自动加上lock in share mode,即使用了共享锁。因此在该隔离级别下,使用的是当前读,而不是快照读。 那么关于是表锁还是行锁,大家可以看到网上最流传的一个说法是这样的InnoDB行锁是通过给索引上的索引项加锁来实现的,这一点MySQL与Oracle不同,后者是通过在数据块中对相应数据行加锁来实现的。 InnoDB这种行锁实现特点意味着:只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁!这句话大家可以搜一下,都是你抄我的,我抄你的。那么,这句话本身有两处错误!错误一: 并不是用表锁来实现锁表的操作,而是利用了Next-Key Locks,也可以理解为是用了行锁+间隙锁来实现锁表的操作!为了便于说明,我来个例子,假设有表数据如下,pId为主键索引pId(int)name(varchar)num(int)1aaa1002bbb2007ccc200执行语句(name列无索引)select * from table where name = aaa for update那么此时在pId=1,2,7这三条记录上存在行锁(把行锁住了)。另外,在(-,1)(1,2)(2,7)(7,+)上存在间隙锁(把间隙锁住了)。因此,给人一种整个表锁住的错觉!ps: 对该结论有疑问的,可自行执行show engine innodb status;语句进行分析。错误二: 所有文章都不提隔离级别!注意上面说的,之所以能够锁表,是通过行锁+间隙锁来实现的。那么,RU和RC都不存在间隙锁,这种说法在RU和RC中还能成立么?因此,该说法只在RR和Serializable中是成立的。如果隔离级别为RU和RC,无论条件列上是否有索引,都不会锁表,只锁行!分析 下面来对开始的问题作出解答,假设有表如下,pId为主键索引pId(int)name(varchar)num(int)1aaa1002bbb2003bbb3007ccc200RC/RU+条件列非索引1. select * from table where num = 200不加任何锁,是快照读。 2. select * from table where num > 200不加任何锁,是快照读。 3. select * from table where num = 200 lock in share mode当num = 200,有两条记录。这两条记录对应的pId=2,7,因此在pId=2,7的聚簇索引上加行级S锁,采用当前读。 4. select * from table where num > 200 lock in share mode当num > 200,有一条记录。这条记录对应的pId=3,因此在pId=3的聚簇索引上加上行级S锁,采用当前读。 5. select * from table where num = 200 for update当num = 200,有两条记录。这两条记录对应的pId=2,7,因此在pId=2,7的聚簇索引上加行级X锁,采用当前读。 6. select * from table where num > 200 for update当num > 200,有一条记录。这条记录对应的pId=3,因此在pId=3的聚簇索引上加上行级X锁,采用当前读。 RC/RU+条件列是聚簇索引恩,大家应该知道pId是主键列,因此pId用的就是聚簇索引。此情况其实和RC/RU+条件列非索引情况是类似的。1. select * from table where pId = 2不加任何锁,是快照读。 2. select * from table where pId > 2不加任何锁,是快照读。 3. select * from table where pId = 2 lock in share mode在pId=2的聚簇索引上,加S锁,为当前读。 4. select * from table where pId > 2 lock in share mode在pId=3,7的聚簇索引上,加S锁,为当前读。 5. select * from table where pId = 2 for update在pId=2的聚簇索引上,加X锁,为当前读。 6. select * from table where pId > 2 for update在pId=3,7的聚簇索引上,加X锁,为当前读。 为什么条件列加不加索引,加锁情况是一样的?其实是不一样的。在RC/RU隔离级别中,MySQL Server做了优化。在条件列没有索引的情况下,尽管通过聚簇索引来扫描全表,进行全表加锁。但是,MySQL Server层会进行过滤并把不符合条件的锁当即释放掉,因此你看起来最终结果是一样的。但是RC/RU+条件列非索引比本例多了一个释放不符合条件的锁的过程!RC/RU+条件列是非聚簇索引我们在num列上建上非唯一索引。此时有一棵聚簇索引(主键索引,pId)形成的B+索引树,其叶子节点为硬盘上的真实数据。以及另一棵非聚簇索引(非唯一索引,num)形成的B+索引树,其叶子节点依然为索引节点,保存了num列的字段值,和对应的聚簇索引。接下来分析开始1. select * from table where num = 200不加任何锁,是快照读。 2. select * from table where num > 200不加任何锁,是快照读。 3. select * from table where num = 200 lock in share mode当num = 200,由于num列上有索引,因此先在 num = 200的两条索引记录上加行级S锁。接着,去聚簇索引树上查询,这两条记录对应的pId=2,7,因此在pId=2,7的聚簇索引上加行级S锁,采用当前读。 4. select * from table where num > 200 lock in share mode当num > 200,由于num列上有索引,因此先在符合条件的 num = 300的一条索引记录上加行级S锁。接着,去聚簇索引树上查询,这条记录对应的pId=3,因此在pId=3的聚簇索引上加行级S锁,采用当前读。 5. select * from table where num = 200 for update当num = 200,由于num列上有索引,因此先在 num = 200的两条索引记录上加行级X锁。接着,去聚簇索引树上查询,这两条记录对应的pId=2,7,因此在pId=2,7的聚簇索引上加行级X锁,采用当前读。 6. sel

注意事项

本文(面试必会系列之MySQL锁)为本站会员(y****1)主动上传,金锄头文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即阅读金锄头文库的“版权提示”【网址:https://www.jinchutou.com/h-59.html】,按提示上传提交保证函及证明材料,经审查核实后我们立即给予删除!

温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




关于金锄头网 - 版权申诉 - 免责声明 - 诚邀英才 - 联系我们
手机版 | 川公网安备 51140202000112号 | 经营许可证(蜀ICP备13022795号)
©2008-2016 by Sichuan Goldhoe Inc. All Rights Reserved.