MqSql的加锁分析
博客专区 > cpf2016 的博客 > 博客详情
MqSql的加锁分析
cpf2016 发表于1年前
MqSql的加锁分析
  • 发表于 1年前
  • 阅读 22
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 新注册用户 域名抢购1元起>>>   

(1)MVCC与基于锁的并发控制

             MySql的InnoDB引擎,实现的是基于多版本的并发控制协议:MVCC。

             MVCC最大的好处,即读不加锁,读写不冲突。在读多于写的应用中,读写不冲突是非常重要的,极大的增强了系统的并发性能。这也就是为什么,几乎所有的RDBMS都支持了MVCC。

             

(2)快照读与当前读

          1.快照读

                简单的select操作,属于快照读,不加锁(当然如果是Serializable隔离级别还是要加锁)

                如:select * from table where ?

 

          2.当前读

                包括特殊的读操作,插入、更新、删除操作,都属于当前读,需要加锁

                如:

                     select * from table where ? lock in share mode;

                     select * from table where ? for update;

                     insert into table values(...);

                     update table set ? where ?

                     delete from table where?

                  所有以上语句,都属于当前读,读取记录的最新版本。并且读取之后,还要保证其他并发事务不能修改当前记录,对读取的记录加锁。

                 其中,除了第一条语句,对读取记录加S锁(共享锁)以外,其他的操作,都加的是X锁(排他锁)

 

          3.为何插入、更新、删除操作都属于当前读?

                 更新操作的执行流程如下:

                

              从图中可以看到一个update操作的具体流程:

              1.update sql发送到mysql后,mysql server会根据where条件,读取第一条满足条件的记录,然后InnoDB引擎会将第一条记录返回,并对记录加锁

              2.mysql server收到这条加锁的记录后,会再发起一个update请求,更新这条记录

              3.这条记录操作完成,再读取下一条记录,直至没有满足条件的记录为止 。

              注意:针对一条当前读的sql,InnoDB与mysql server的交互,是一条条进行的,因此加锁也是一条条进行的。

                        先对一条满足条件的记录加锁,返回给mysql server,做一些DML操作;然后再读取下一条并加锁,直至读取完毕

 

(3)2PL:Two-Phase Locking

             传统的RDBMS加锁的一个原则就是2PL(二阶段锁)。

             简单地说就是锁操作分为2个阶段:加锁阶段与解锁阶段,并且保证加锁阶段与解锁阶段不相交。

                   

             从上图可以看出,2PL就是将加锁、解锁分为2个完全不相交的阶段:加锁阶段:只加锁不放锁,解锁阶段:只放锁不加锁

 

(4)隔离级别与加锁

           1.read uncommitted

               读未提交,不会使用,忽略

           2.read committed(RC)

               快照读不加锁

               当前读,RC隔离级别保证对读取到的记录加锁,但存在幻读情况

           3.repeatable read (RR)

               快照读不加锁

               当前读,RR隔离级别保证对读到的记录加锁,同时保证对读取的范围加锁,因此新的满足查询条件的记录不能够插入(间隙锁),因而不存在幻读情况

           4.serializable

               从MVCC退化为基于锁的并发控制。不区别快照读和当前读,所有的读操作均为当前读,读加读锁(S锁),写加写锁(X锁)

               serializable隔离级别下,读写冲突,因此并发度急剧下降,不建议使用。

 

(5)加锁分析

             因为快照读在RC、RR下都不加锁,所以我们不讨论快照读,而只讨论当前读的情况

             接下来以delete from t1 where id=10这条sql为例,来分析加锁的情况

            1.id主键+RC

                 这个组合最为简单。因为id为主键,where的条件为id=10,所以只需要在id=10的记录上加X锁即可

               

     

            2.id唯一键+RC

                 name为主键,id为唯一键,那么在RC隔离级别下,delete from t1 where id=10需要如何加锁呢?

                

                先对唯一索引树上id=10的记录加上X锁,然后因为id=10对应的是name=d,那么从主键索引上查找到name=d的记录,然后对这条记录加X锁。

 

            3.id非唯一键索引+RC

             

             此时在id的索引树上id=10的有2条记录,所以先对这2条记录加锁。

             然后因为name是主键,所以在主键索引上查找到name=b和name=d的记录,然后对这2条记录加锁

            4.id无索引+RC

                 因为id无索引,所以就只能全表扫描了,此时会对所有记录加X锁(但实际情况会优化)

                 

 

            5.id主键+RR

                 id列是主键,RR隔离级别,这条sql与在RC级别下一致,都是对这条记录加X锁

            6.id唯一键+RR

                 与RC下一致,也是先对唯一索引树上记录加X锁,然后对主键索引树上对应记录加X锁

            7.id非唯一键+RR

                 

               这与RC隔离级别下有很大差别,主要是多了一个gap锁,而且gap锁是加在记录之间,而不是加在记录之上

               gap锁有什么用呢?实际上这个gap锁就是RR隔离级别,这是相对于RC隔离级别而言,不会出现幻读的关键。

               gap锁锁住的位置,不是记录本身,而是2条记录之间的gap。所谓幻读,就是在同一个事务中,连续做两次当前读,比如select * from t1 where id =10 for update,出现了2次记录数量不一致的情况,就好像见到鬼了。

               那么如何保证两次当前读返回一致的记录数呢?那就需要根据where条件确定记录范围,然后保证在这个范围内,不会被其他事物插入新的、满足条件的记录。(举个例子:假如条件为select * from table id>5 and id <10,而表中只有id=7,id=8两条记录满足条件,如果有了gap锁,那么就会将id=6的左边和id=7的右边边界加上gap锁,这样如果其他事务要插入一条id=9的记录,就需要等待了)这就是gap锁的作用。

                           7.id无索引+RR

                              这种情况必须要进行全表扫描,因而需要首先需要对所有记录加X锁,并且为了防止幻读,对所有数据的间隙加上了gap锁

                              

                               此时全表被锁死,无法更新、删除、插入

                           8.serializable

                               读写全部加X锁

 

 

共有 人打赏支持
粉丝 3
博文 3
码字总数 136323
×
cpf2016
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: