Innodb锁分析

Innodb:

• Innodb存储引擎支持行锁和表锁(另类的行锁)

• Innodb的 可重复读隔离级别(RR) 解决了幻影读的问题(锁和MVCC) 

• Innodb 的行锁是基于索引的(行锁必须通过索引的检索) 如果加锁的是二级索引,对应的主键的innodb的一级索引也会被锁住.执行删除和修改的时候好寻思条件又没有索引

• 加S锁与X锁命令

  • 共享锁（S）： SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。

  • 排他锁（X)： SELECT * FROM table_name WHERE ... FOR UPDATE。

  • 注意:是否使用索引是由Mysql通过代价来决定,所以有时候,及时有索引也会进行全表扫描从而加表锁.记得别忘了检查执行计划.还有一种方式就是 FORCE index 强制使用该索引.

• 其他类型锁:

  • Next-Key Lock =Gap Lock+Record lock

  • 间隙锁(Gap  RR的隔离级别才存在):

  • 

  • 临键锁(Next-key ):

  • •  

      

      左开右闭  命中数据所在的区间与命中数据的下一个区间 

    • 作用为防止幻读

  • 记录锁

  • •  

      

      此种条件下 假设4不是唯一索引  它会锁住(1,4)

• 默认条件下 使用insert..select 或者 create...select 会对source_table加上共享锁有必要还会加间隙锁  为了防止binlog同步时其他session在这个事务之前篡改数据

•             用 SELECT...FOR UPDATE 加排他锁， 在没有符合该条件记录情况下， 两个线程都会加锁成功。

              程序发现记录尚不存在， 就试图插入一条新记录， 如果两个线程都这么做， 就会出现死锁。

               这种情况下， 将隔离级别改成 READ COMMITTED,就可以避免问题.

  • 容易忽视的死锁:

    • 在 REPEATABLE-READ 隔离级别下， 如果两个线程同时对相同条件记录

    •  用 SELECT...FOR UPDATE 加排他锁， 在没有符合该条件记录情况下， 两个线程都会加锁成功。

         程序发现记录尚不存在， 就试图插入一条新记录， 如果两个线程都这么做， 就会出现死锁。

           这种情况下， 将隔离级别改成 READ COMMITTED,就可以避免问题.