mysql杂说——mysql锁

  Mysql用到了不少这种锁机制，行锁，表锁等，读锁，写锁等，都是在作操做以前先上锁。这些锁统称为悲观锁(Pessimistic Lock)。

一、mysql存储引擎分为：innodb 和 myisam

                 事务，             表锁            行锁 

innodb      支持                 支持            支持　　　   

myisam     不支持　　　  支持　　　 不支持

二、数据库锁：行锁的是索引

      加锁的目的：减小资源的竞争

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的几率最高，并发度最低。 
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的几率最低，并发度也最高。 
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度通常 

 

三、

 

 

 mysql5.7解决了幻读：解决思路经过间隙锁防止幻读，以知足相关隔离级别的要求

间隙锁：1,3,5           存在(-∞,1),(1,3)，(3,5)，(5,∞) 四个间隙，分别存在4个间隙锁

四、InnoDB实现了如下两种类型的行锁。

• 共享锁（s）：又称读锁。容许一个事务去读一行，阻止其余事务得到相同数据集的排他锁。若事务T对数据对象A加上S锁，则事务T能够读A但不能修改A，其余事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其余事务能够读A，但在T释放A上的S锁以前不能对A作任何修改。
• 排他锁（Ｘ）：又称写锁。容许获取排他锁的事务更新数据，阻止其余事务取得相同的数据集共享读锁和排他写锁。若事务T对数据对象A加上X锁，事务T能够读A也能够修改A，其余事务不能再对A加任何锁，直到T释放A上的锁。

对于共享锁你们可能很好理解，就是多个事务只能读数据不能改数据。 
对于排他锁你们的理解可能就有些差异，我当初就犯了一个错误，觉得排他锁锁住一行数据后，其余事务就不能读取和修改该行数据，其实不是这样的。排他锁指的是一个事务在一行数据加上排他锁后，其余事务不能再在其上加其余的锁。mysql InnoDB引擎默认的修改数据语句：update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，若是加排他锁可使用select …for update语句，加共享锁可使用select … lock in share mode语句。因此加过排他锁的数据行在其余事务种是不能修改数据的，也不能经过for update和lock in share mode锁的方式查询数据，但能够直接经过select …from…查询数据，由于普通查询没有任何锁机制。

五、为了容许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁。

• 意向共享锁（IS）：事务打算给数据行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
• 意向排他锁（IX）：事务打算给数据行加排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。

我的总结：意向共享锁（IS）和意向排他锁（IX）就是一个标志。在加共享锁（s）和排他锁（Ｘ）以前看看数据库有没有意向锁，目的：提升数据库加锁效率。

六、InnoDB行锁模式兼容性列表: 

 

 

 7：InnoDB行锁是经过给索引上的索引项加锁来实现的，InnoDB这种行锁实现特色意味着：只有经过索引条件检索数据，InnoDB才使用行级锁，不然，InnoDB将使用表锁！ 

注意：因为MySQL的行锁是针对索引加的锁，不是针对记录加的锁，因此虽然是访问不一样行的记录，可是若是是使用相同的索引键，是会出现锁冲突的

八、几种概念：

间隙锁：当咱们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的 索引项加锁；对于键值在条件范围内但并不存在的记录，叫作“间隙（GAP)”，InnoDB也会对这个“间隙”加锁。

 

小结：

 

对于InnoDB表，本文主要讨论了如下几项内容： 
（1）InnoDB的行锁是基于索引实现的，若是不经过索引访问数据，InnoDB会使用表锁。 
（2）介绍了InnoDB间隙锁（Next-key)机制，以及InnoDB使用间隙锁的缘由。 
在不一样的隔离级别下，InnoDB的锁机制和一致性读策略不一样。

 

在了解InnoDB锁特性后，用户能够经过设计和SQL调整等措施减小锁冲突和死锁，包括：

 

• 尽可能使用较低的隔离级别； 精心设计索引，并尽可能使用索引访问数据，使加锁更精确，从而减小锁冲突的机会；
• 选择合理的事务大小，小事务发生锁冲突的概率也更小；
• 给记录集显式加锁时，最好一次性请求足够级别的锁。好比要修改数据的话，最好直接申请排他锁，而不是先申请共享锁，修改时再请求排他锁，这样容易产生死锁；
• 不一样的程序访问一组表时，应尽可能约定以相同的顺序访问各表，对一个表而言，尽量以固定的顺序存取表中的行。这样能够大大减小死锁的机会；
• 尽可能用相等条件访问数据，这样能够避免间隙锁对并发插入的影响； 不要申请超过实际须要的锁级别；除非必须，查询时不要显示加锁；
• 对于一些特定的事务，可使用表锁来提升处理速度或减小死锁的可能。

 

博客原文：http://www.javashuo.com/article/p-fqrzmnlo-kv.html