MySQL(InnoDB剖析):---锁之（阻塞、死锁、锁升级）

一、阻塞

• 因为不同锁之间的兼容性问题，在有些时刻一个事务中的锁需要等待另一个事务中的锁释放它所占用的资源，这就是阻塞。阻塞并不是一件坏事，其是为了确保事务可以并发且正常地运行

 

nnodb_lock_wait_timeout参数

• 该参数控制锁发生阻塞时等待的时间（默认是50秒）
• 

• 该参数是动态的，因此可以在数据库运行时设置
• 在超时之后数据库会抛出一个1025的错误，如下：

innodb_roolback_on_timeout参数

• 用来设定是否在等待超时时对进行中的事务进行回滚操作（默认为OFF，代表不回滚）
• 该参数是静态的，因此不可以在数据库运行时设置

• 默认情况下，InnoDB不会回滚超时引发的错误异常。其实InnoDB在大部分情况下都不会对超时的事务进行回滚（死锁除外，见下面死锁的演示案例），因此用户必须判断是否需要commit还是rollback，然后再进行下一步的操作

演示案例

• 一个表t中有3行数据
• 会话A：开启一个是事务，然后查询表t中小于4的字段值，并且加X锁
  • 在Next-Key Lock算法（REPEATABLE READ隔离级别下）下锁定了小于4的所有记录（其中也锁定了4这个记录本身）
• 会话B：开启一个事务，然后向表中插入一行数据5（此SQL语句可以执行），然后再插入数据3（因为记录3在会话A中被锁定了），因此会话B此时阻塞
• 会话B：阻塞一会儿后，会话B超时（如下图所示），超时之后再次进行查询操作，发现5这个记录插入成功（因为默认情况下，阻塞超时事务没有回滚）

 

二、死锁

• 死锁是指：两个或两个以上的事务在执行过程中，因争夺资源而造成的一种互相等待的现象。若无外力作用，事务都将无法推进下去

解决死锁方式①

• 解决死锁问题最简单的方式：是不要有等待，将任何的等待都转换为回滚，并且事务重新开始
• 毫无疑问，这的确可以避免死锁问题的产生。而然在线上环境中，这可能导致并发性能下降，甚至任何一个事务都不能进行。而这所带来的的问题远比死锁问题更为严重，因为这很难被发现并且浪费资源

解决死锁方式②

• 解决死锁还有一个方式是超时，即当两个事务互相等待时，当一个等待时间超过设置的某一阈值，其中的一个事务进行回滚，另一个等待事务就能继续进行
• 在上面的介绍中，参数innodb_lock_wait_timeout参数用来设置超时的时间