暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

MySQL死锁套路:唯一索引S锁与X锁的爱恨情仇

数据和云 2019-05-22
249

利用调试MySQL源码的方式来查看死锁的过程,本文举了个通俗易懂的例子方便大家理解,希望可以对大家有帮助。


毫不夸张的说,有一半以上的死锁问题由唯一索引贡献,后面介绍的很多死锁的问题都跟唯一索引有关。这次我们讲一段唯一索引 S 锁与 X 锁的爱恨情仇。


我们来看一个简化过的例子

    # 构造数据
    CREATE TABLE `t1` (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `name` varchar(10),
    `level` int(11),
    PRIMARY KEY (`id`),
    UNIQUE KEY `uk_name` (`name`)
    );
    INSERT INTO `t1` (`name`, `level`) VALUES ('A',0);
    # 出现问题的sql语句如下,并发情况下就会出现死锁
    INSERT ignore INTO `t1` (`name`, `level`) VALUES ('A',0);
    update t1 set level = 1 where name = "A";


    我们用之前介绍过的源码分析方式,先来看下这两条语句分别加什么锁,然后分析死锁形成的过程。


    第一条语句

      INSERT ignore INTO t1 (name, level) VALUES ('A',0);


      在调试中得到的结果如下



      可以看到这条语句对唯一键 uk_name 加共享锁(S锁),而且成功。


      第二条语句

        update t1 set level = 1 where name = "A"; 通过唯一键更新数据库字段。


        这种情况在之前的文章已经介绍过,会对唯一索引加 X 锁,然后对主键索引加 X 锁




        这样就可以非常轻松的复现死锁的问题了,步骤如下


        1. 开启两个 session,分别 begin

        2. session1 执行INSERT ignore INTO t1 (name, level) VALUES ('A',0);

        3. session2 执行INSERT ignore INTO t1 (name, level) VALUES ('A',0);

        4. session1 执行update t1 set level = 1 where name = "A"; 进入等待状态

        5. session2 执行update t1 set level = 1 where name = "A";,死锁产生,被回滚,同时事务 1 执行成功


        详细的锁状态变化如下



        死锁日志如下:

          LATEST DETECTED DEADLOCK
          ------------------------
          181208 23:00:52
          *** (1) TRANSACTION:
          TRANSACTION 53A7, ACTIVE 162 sec starting index read
          mysql tables in use 1, locked 1
          LOCK WAIT 3 lock struct(s), heap size 376, 2 row lock(s)
          MySQL thread id 12, OS thread handle 0x700010522000, query id 1424 localhost root Updating
          update t1 set level = 1 where name = "A"
          *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
          RECORD LOCKS space id 89 page no 4 n bits 72 index `uk_name` of table `lock_demo2`.`t1` trx id 53A7 lock_mode X locks rec but not gap waiting
          Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
          0: len 1; hex 41; asc A;;
          1: len 4; hex 80000001; asc ;;


          *** (2) TRANSACTION:
          TRANSACTION 53A8, ACTIVE 8 sec starting index read
          mysql tables in use 1, locked 1
          3 lock struct(s), heap size 376, 2 row lock(s)
          MySQL thread id 96, OS thread handle 0x70001062e000, query id 1425 localhost root Updating
          update t1 set level = 1 where name = "A"
          *** (2) HOLDS THE LOCK(S):
          RECORD LOCKS space id 89 page no 4 n bits 72 index `uk_name` of table `lock_demo2`.`t1` trx id 53A8 lock mode S
          Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
          0: len 1; hex 41; asc A;;
          1: len 4; hex 80000001; asc ;;


          *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
          RECORD LOCKS space id 89 page no 4 n bits 72 index `uk_name` of table `lock_demo2`.`t1` trx id 53A8 lock_mode X locks rec but not gap waiting
          Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
          0: len 1; hex 41; asc A;;
          1: len 4; hex 80000001; asc ;;


          *** WE ROLL BACK TRANSACTION (2)


          来详细看一下这个死锁日志:


            *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 89 page no 4 n bits 72 index uk_name of table lock_demo2.t1 trx id 53A7 lock_mode X locks rec but not gap waiting


            事务 1 想获取 uk_name 唯一索引上的 X 锁 (非 gap 锁的记录锁)


              *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 89 page no 4 n bits 72 index uk_name of table lock_demo2.t1 trx id 53A8 lock mode S


              事务 2 持有uk_name 唯一索引上的 S 锁(共享锁)


                *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 89 page no 4 n bits 72 index uk_name of table lock_demo2.t1 trx id 53A8 lock_mode X locks rec but not gap waiting


                事务 2 想获得 uk_name 唯一索引上的 X 锁(非 gap 锁的记录锁)


                跟之前理论上推断的结论是一致。


                编辑推荐



                1. 腾讯面试:一条SQL语句执行得很慢的原因有哪些?

                2. 40页PPT分享万亿级交易量下的支付平台设计

                3. Oracle/云MySQL/MsSQL“大迁移”真相及最优方案

                4. 让MySQL速度提升3倍的19种优化方式


                出处:https://juejin.im/post/5ce3cfa46fb9a07ece67a4a9

                编辑:尹文敏


                公司简介 | 恩墨学院 | 招聘 | DTCC | 数据技术嘉年华 | 免费课程 | 入驻华为严选商城

                  

                zCloud | SQM | Bethune Pro2 zData一体机 | Mydata一体机 | ZDBM 备份一体机

                Oracle技术架构 | 免费课程 | 数据库排行榜 | DBASK问题集萃 | 技术通讯 

                升级迁移 | 性能优化 | 智能整合 安全保障 | 

                云和恩墨大讲堂 | 一个分享交流的地方

                长按,识别二维码,加入万人交流社群


                请备注:云和恩墨大讲堂

                文章转载自数据和云,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

                评论