MySQL系列（五）---总结MySQL中的锁

MySQL中的锁

目录

• MySQL系列（一）：基础知识大总结
• MySQL系列（二）：MySQL事务
• MySQL系列（三）：索引
• [MySQL系列（四）：引擎](http://www.cnblogs.com/-new/p/7279777.html l )
• MySQL系列（五）：总结MySQL中的锁

概述

• MyISAM支持表锁，InnoDB支持表锁和行锁，默认为行锁

• 表级锁：开销小，加锁快，不会出现死锁。锁定粒度大，发生锁冲突的概率最高，并发量最低

• 行级锁：开销大，加锁慢，会出现死锁。锁力度小，发生锁冲突的概率小，并发度最高

MyISAM表级锁

锁模式

• show status like 'table%' 可以分析锁争夺情况
• 表级锁分为两种模式：共享读锁，独占写锁
• 读读共享，读写互斥，写写互斥，写读互斥（比如写读互斥，当一个用户对user表进行写的时候，会阻塞其他用户的写操作和读操作）

加表锁

• 在select的时候自动加读锁，在update delete insert时，自动加写锁
• 一般不需要用户用lock table 命令直接显式加锁

显示加表锁时

• session1显示给user表加锁

lock table user read;

• session1此时不能读取未锁定的class表，所以lock table时要一次性锁定要用到的表
• session1此时不能进行更新和插入，只能进行读取
• 其他session可以读取user表，但是更新会阻塞，而插入不会阻塞（可以通过设置concurrent_insert 系统变量来控制并发插入行为）

锁调度

• 当一个进程请求user表的读锁，一个进程请求user表的写锁，即使读请求先到，也是请求写锁成先成功
• 所以，MyISAM不适合大量的更新，因为大量更新会导致查操作很难获得读锁

InnoDB行级锁

行锁

• 通过 show status like 'InnoDB_row_lock' 来分析行锁争夺情况
• 共享锁S：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁
• 排他锁X：允许获得排它锁的事务更新数据，阻止其他事务取得相同数据集的共享锁和排他锁

意向锁

• 所谓意向锁就是意图拿到锁，所以要获得共享锁时，需要先获得意向共享锁
• 意向共享所IS，一个事务给一个数据行加共享锁时，必须先获得表的IS锁
• 意向排它锁IX，一个事务给一个数据行加排他锁时，必须先获得该表的IX锁

间隙锁

• 范围查询时，比如select * from user where id>50 ，这个时候即使最大id为51，不仅会给符合条件的行加锁，也会给id大于51（不存在的记录）的加锁，这就是间隙锁
• 间隙锁解决了事务并发的幻读问题

兼容情况

锁	S	X	IS	IX
S	Yes	No	Yes	No
X	No	No	No	No
IS	Yes	No	Yes	Yes
IX	No	No	Yes	Yes

加锁

• 意向锁是InnoDB自动加的
• 对于update insert delete 会自动加排它锁
• 对于select不会自动加锁
• Select * from user LOCK IN SHARE MODE 手动添加共享锁
• select * from user For update 手动添加排它锁

行锁使用方式

• 通过索引条件检索数据时，才使用行锁，否则用表锁
• 也就是如果select的where列不是索引列，那么此时，实际上是给整个表加锁
• 检索条件是索引时，又分索引是聚集索引还是非聚集索引，如果是聚集索引（索引上叶节点存放的整条记录），在聚集索引上的加上行锁，而如果是非聚集索引，要在非聚集索引记录上加行锁，又要在聚集索引上加行锁

什么时候使用表锁

• 事务需要更新表的大部分数据。如果每一行都加上排他锁，锁冲突严重，那么此时执行效率低
• 事务涉及多个表，比较复杂

死锁

MyISAM

• 由于加的是表锁，一次性锁定要需要的表，所以不会出现死锁

InnoDB

• 死锁一般是事务相互等待对方资源
• 发生死锁后，会自动检测，并让一个事务释放锁并回退

session1	session2
update user set username='jiajun' where id=1	update user set username='jiajun' where id=2
update user set username='jiajun' where id=2	update user set username='jiajun' where id=1

• 上面就是死锁的列子

乐观锁与悲观锁

• 乐观锁和悲观锁是一种思想，不是上面提到的数据库提供的锁，是并发控制的一种手段
• 有这样的场景，两个事务对商品（id=666）进行下单

乐观锁

• 有一个statu字段，未下单为0，下单为1
• 先查statu字段，下单进行更新， 再查询一次statu看是否与之前查的一样，一样的话commit，不一样的话rollback
• 实现方式：加一个版本号或者时间戳，提交前进行一次比较

悲观锁

• 直接对id为666的行加排他锁
• 实现方式：通过数据库的锁机制进行加锁

对比

• 悲观锁比较谨慎，采用加锁机制，一定程度下降低了并发性
• 乐观锁认为一般情况下不会发生冲突，并发性较好
• 从冲突量和重试代价来衡量，如果冲突很少，或者重试代价不会很严重，那么通常情况下应该选择乐观锁，因为它能得到更好的并发性，而且更容易实现。但是，如果冲突的代价严重，那么就需要使用悲观策略

两段锁原则

两段锁

• 是一个加锁原则，一种协议
• 锁操作分为两个阶段，加锁阶段只加锁不放锁，解锁阶段只放锁不加锁
• 比如一个事务中两个update语句，此时执行完第一个update不会立刻放锁，等加锁阶段完成后再进行放锁，也就是加锁和解锁不相交
• 事务开始后就处于加锁阶段，一直到执行ROLLBACK和COMMIT之前都是加锁阶段。ROLLBACK和COMMIT使事务进入解锁阶段，即在ROLLBACK和COMMIT模块中DBMS释放所有封锁。

我觉得分享是一种精神，分享是我的乐趣所在，不是说我觉得我讲得一定是对的，我讲得可能很多是不对的，但是我希望我讲的东西是我人生的体验和思考，是给很多人反思，也许给你一秒钟、半秒钟，哪怕说一句话有点道理，引发自己内心的感触，这就是我最大的价值。（这是我喜欢的一句话，也是我写博客的初衷）

作者：jiajun 出处： http://www.cnblogs.com/-new/

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。如果觉得还有帮助的话，可以点一下右下角的【推荐】，希望能够持续的为大家带来好的技术文章！想跟我一起进步么？那就【关注】我吧。