【mysql】- 锁篇

回顾

问题

  • 事务并发执行时可能带来各种问题，并发事务访问相同记录的情况大致可以划分为3种
    • 读-读情况：即并发事务相继读取相同的记录
      • 读取操作本身不会对记录有什么影响，并不会引起什么问题，所以允许这种情况的发
    • 写-写情况：即并发事务相继对相同的记录做出改动
      • 任何一种隔离级别都不允许这种问题的发生。所以在多个未提交事务相继对一条记录做改动时，需要让它们排队执行，这个排队的过程其实是通过锁来实现的。这个所谓的锁其实是一个内存中的结构，在事务执行前本来是没有锁的，也就是说一开始是没有锁结构和记录进行关联的
    • 读-写或写-读情况：也就是一个事务进行读取操作，另一个进行改动操作
      • 这种情况下可能发生脏读、不可重复读、幻读的问题

解决上述问题方案

  • 读操作利多版本并发控制（ MVCC ），写操作进行加锁
  • 读、写操作都采用加锁的方案

一致性读（Consistent Reads）

  • 事务利用MVCC 进行的读取操作称之为一致性读，或者一致性性锁读，有的地也称之为快照读。所有普通的SELECT语句（ plain SELECT ）在READ COMMITTED、REPEATABLE READ隔离级别下都算是一致性读，一致性读并不会对表中的任何记录做加锁操作，其他事务可以自由的对表中的记录做改动

锁定读（Locking Reads）

并发事务的读-读情况并不会引起什么问题，不过对于写-写、读-写或写-读这些情况可能会引起一些问题，需要使用MVCC或者加锁的方式来解决它们。在使用加锁的方式解决问题时，由于既要允许读-读情况不受影响，又要使写-写、读-写 或写-读情况中的操作相互阻塞

  • 共享锁和独占锁

    • 共享锁 ，英文名：Shared Locks，简称S锁。在事务要读取一条记录时，需要先获取该记录的S锁
    • 独占锁 ，也常称排他锁，英文名：Exclusive Locks，简称X锁。在事务要改动一条记录时，需要先获取该记录的X锁
    • 上述两种锁的场景
      • 假如事务T1首先获取了一条记录的S锁之后，事务T2接着也要访问这条记录：
        • 如果事务T2想要再获取一个记录的S锁，那么事务T2也会获得该锁，也就意味着事务T1和T2在该记录上同时持有S锁
        • 如果事务T2想要再获取一个记录的X锁，那么此操作会被阻塞，直到事务T1提交之后将S锁释放掉
      • 如果事务T1首先获取了一条记录的X锁之后，那么不管事务T2接着想获取该记录的S锁还是X锁都会被阻塞，直到事务T1提交
      • 故我们说S锁和S锁是兼容的，S锁和X锁是不兼容的，X锁和X锁也是不兼容的

  • 锁定读的语句

    • 在采用加锁方式解决脏读、不可重复读、幻读这些问题时，读取一条记录时需要获取该下该记录的S锁，其实这是不严谨的，有时候想在读取记录时就获取记录的X锁，来禁用别的事务读写该记录
      • 对读取的记录加S锁：
        • 也就是在普通的SELECT语句后边加，如果当前事务执行了该语句，那么它会为读取到的记录加S锁，这样允许别的事务继续获取这些记录的S锁（比方说别的事务也使用语句来读取这些记录），但是不能获取这些记录的X锁（比方说使SELECT ... FOR UPDATE语句来读取这些记录，或者直接修改这些记录）。如果别的事务想要获取这些记录的X锁，那么它们会阻塞，直到当前事务提交之后将这些记录上的S锁释放掉
      • 对读取的记录加X锁：
        • SELECT ... FOR UPDATE; 也就是在普通的SELECT语句后边加FOR UPDATE，如果当前事务执行了该语句，那么它会为读取到的记录加X锁，这样既不允许别的事务获取这些记录的S锁（比方说别的事务使用语句来读取这些记录），也不允许获取这些记录的X锁（比方说使用SELECT ... FOR UPDATE语句来读取这些记录，或者直接修改这些记录）。如果别的事务想要获取这些记录的S锁或者X锁，那么它们会阻塞，直到当前事务提交之后将这些记录上的X锁释放掉

  • 写操作

    • 平常所用到的写操作是DELETE、UPDATE、INSERT这三种：
      • DELETE：对一条记录做DELETE操作的过程其实是先在B+树中定位到这条记录的位置，然后获取一下这条记录的X锁，然后再执行delete mark操作。我们也可以把这个定位待删除记录在B+树中位置的过程看成是一个获取X锁的锁定读
      • UPDATE：
        • 在对一条记录做UPDATE操作时分为三种情况：
          • 如果未修改该记录的键值并且被更新的列占用的存储空间在修改前后未发生变化，则先在B+树中定位到这条记录的位置，然后再获取一下记录的X锁，最后在原记录的位置进行修改操作。其实我们也可以把这个定位待修改记录在B+树中位置的过程看成是一个获取X锁的锁定读
          • 如果未修改该记录的键值并且至少有一个被更新的列占用的存储空间在修改前后发生变化，则先在B+树中定位到这条记录的位置，然后获取一下记录的X锁，将该记录彻底删除掉（就是把记录彻底移入垃圾链表），最后再插入一条新记录。这个定位待修改记录在B+树中位置的过程看成是一个获取X锁的锁定读，新插入的记录由 INSERT操作提供的隐式锁进行保护
          • 如果修改了该记录的键值，则相当于在原记录上做DELETE操作之后再来一次INSERT操作，加锁操作就需要按照DELETE和INSERT的规则进行了
      • NSERT：一般情况下，新插入一条记录的操作并不加锁，通过一种称之为隐式锁来保护这条新插入的记录在本事务提交前不被别的事务访问

前边提到的锁都是针对记录的，也可以被称之为行级锁或者行锁，对一条记录加锁影响的也只是这条记录而已，我们就说这个锁的粒度比较细；其实一个事务也可以在表级别进行加锁，自然就被称之为表级锁或者表锁，对一个表加锁影响整个表中的记录，我们就说这个锁的粒度比较粗。给表加的锁也可以分为共享锁（S锁）和独占锁（X锁）

  • 多粒度锁
    • 给表加S锁：
      • 如果一个事务给表加了S锁，那么：
        • 别的事务可以继续获得该表的S锁
        • 别的事务可以继续获得该表中的某些记录的S锁
        • 别的事务不可以继续获得该表的X锁
        • 别的事务不可以继续获得该表中的某些记录的X锁
    • 给表加X锁：
      • 如果一个事务给表加了X锁（意味着该事务要独占这个表），那么：
        • 别的事务不可以继续获得该表的S锁
        • 别的事务不可以继续获得该表中的某些记录的S锁
        • 别的事务不可以继续获得该表的X锁
        • 别的事务不可以继续获得该表中的某些记录的X锁

InnoDB存储引擎中的锁

  • 表级锁
    • 表级别的S锁、X锁
      • 在对某个表执行SELECT、INSERT、DELETE、UPDATE语句时，InnoDB存储引擎是不会为这个表添加表级别的S锁或者X锁的
    • 表级别的IS锁、IX锁
      • 当我们在对使用InnoDB存储引擎的表的某些记录加S锁之前，那就需要先在表级别加一个IS锁，当我们在对使用InnoDB 存储引擎的表的某些记录加X锁之前，那就需要先在表级别加一个IX锁。IS锁和IX锁的使命只是为了后续在加表级别的S锁和X锁时判断表中是否有已经被加锁的记录，以避免用遍历的方式来查看表中有没有上锁的记录
    • 表级别的AUTO-INC锁
      • 在使用MySQL过程中，我们可以为表的某个列添加AUTO_INCREMENT属性，之后在插入记录时，可以不指定该列的值，系统会自动为它赋上递增的值
  • 行级锁：
    • 行锁，也称为记录锁 ，顾名思义就是在记录上加的锁
    • 行锁类型
      • Record Locks：有S锁和X锁之分,当一个事务获取了一条记录的S型记录锁后，其他事务也可以继续获取该记录的S型记录锁，但不可以继续获取X型记录锁；当一个事务获取了一条记录的X型记录锁后，其他事务既不可以继续获取该记录的S型记录锁，也不可以继续获取X型记录锁
      • Gap Locks：可以用于解决可重复读级别下的幻读问题，防止插入幻影记录
      • Next-Key Locks: 锁住某条记录同时又可以阻止其他事务在该条记录前边的间隙插入新纪录，其是Record Locks和gap Locks的合体它既能保护该条记录，又能阻止别的事务将新记录插入被保护记录前边的间隙
      • Insert Intention Locks：一个事务在插入一条记录时需要判断一下插入位置是不是被别的事务加了所谓的gap锁，若存在，插入操作需要等待，直到拥有的gap锁对应的事务提交，事务在等待的时候也需要在内存中生成一个锁结构，表明有事务想在某个间隙中插入新纪录，但是现在在等待。这种类型的锁命名为Insert Intention Locks，也成为插入意向锁
      • 隐式锁：一个事务在执行INSERT操作时，如果即将插入的间隙已经被其他事务加了gap锁，那么本次INSERT操作会阻塞，并且当前事务会在该间隙上加一个插入意向锁，否则一般情况下INSERT操作是不加锁的

内存结构

  • 加锁的本质就是在内存中创建一个锁结构与之关联
    • 对于需要放在同一个锁结构中的情况
      • 在同一个事务中进行加锁操作
      • 被加锁的记录在同一个页面中
      • 加锁的类型是一样的
      • 等待状态是一样的
  • 锁结构
    • 锁所在的事务信息： 不论是表锁还是行锁，都是在事务执行过程中生成的，哪个事务生成了这个锁结构，这里就记载着这个事务的信息。其本质是一个指针，通过该指针可以找到内存中关于该事务的更多信息
    • 索引信息：对于行锁来说，需要记录一下加锁的记录是属于哪个索引的
    • 表锁/行级信息：
      • 表锁：记载着这是对哪个表加的锁，还有其他的一些信息
      • 行锁：记载了三个重要的信息
        • Space ID ：记录所在表空间。
        • Page Number ：记录所在页号。
        • n_bits ：对于行锁来说，一条记录就对应着一个比特位，一个页面中包含很多记录，用不同的比特位来区分到底是哪一条记录加了锁。为此在行锁结构的末尾放置了一堆比特位，这个n_bits属性代表使用了多少比特位
    • type_mode：这是一个32位的数，被分成了lock_mode、lock_type和rec_lock_type三个部分
      • 锁的模式（ lock_mode ），占用低4位
        • LOCK_IS（十进制的0）：表示共享意向锁，也就是IS锁。
        • LOCK_IX（十进制的1）：表示独占意向锁，也就是IX锁。
        • LOCK_S（十进制的2）：表示共享锁，也就是S锁。
        • LOCK_X（十进制的3）：表示独占锁，也就是X锁。
        • LOCK_AUTO_INC（十进制的4）：表示AUTO-INC锁。
      • 锁的类型（ lock_type ），占用第5〜8位，不过现阶段只有第5位和第6位被使用：
        • LOCK_TABLE（十进制的16），也就是当第5个比特位置为1时，表示表级锁。
        • LOCK_REC（十进制的32），也就是当第6个比特位置为1时，表示行级锁
      • 行锁的具体类型（rec_lock_type），使用其余的位来表示。只有在lock_type的值为LOCK_REC时，也就是只有在该锁为行级锁时，才会被细分为更多的类型：
        • LOCK_ORDINARY（十进制的0）：表示next-key锁 。
        • LOCK_GAP（十进制的512）：也就是当第10个比特位置为1时，表示gap锁 。
        • LOCK_REC_NOT_GAP（十进制的1024）：也就是当第11个比特位置为1时，表示记录锁。
        • LOCK_INSERT_INTENTION（十进制的2048）：也就是当第12个比特位置为1时，表示插入意向锁
posted @ 2021-01-05 16:23  双木l之林  阅读(89)  评论(0)  编辑  收藏  举报