MySQL的行锁，死锁

简介

MySQL的行锁是在引擎层由各个引擎自己实现的，并不是所有引擎都支持行锁，比如MylSAM就不支持行锁，不支持行锁意味着他的并发控制只能使用表锁，这样就会很影响业务的并发度，因为它锁的范围更大，InnoDB支持行锁的，这也是MyISAM被InnoDB替代的原因之一。

行锁

行锁是指针对数据库中表中每行数据的锁，当一个事务A对这行数据进行更新时，另一个事务B也要对这行数据更新，那么必须要等事务A的操作完成过后才可以更新。

俩阶段锁协议

如图所示：事务B的update语句会被堵塞，直到事务A执行commit之后，事务B才能继续执行。

也就是说在InnoDB事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放，这个就是俩阶段锁协议。

如果这个事务中的某一条语句执行完，没有立刻释放锁，那么另外一个事务需要这个行锁的时候，就会导致需要等待很长的时间，所以根据俩阶段锁协议，我们可以合理安排语句的执行顺序，将并发度高的语句放到最后执行，这样可以很大程度上减少事务之间的锁等待，提生了并发度。

死锁和死锁检测

概念：当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无线等待的状态，称为死锁。

举例

这时候，事务A在等待事务B释放id=2的行锁，而事务B在等待事务A释放id=1的行锁。事务A和事务B在互相等待对方的资源释放，就是进入了死锁状态。当出现死锁以后有俩种策略：

• 一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout来设置
• 发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on,表示开启这个逻辑。

问题：如果采用第一种策略，出现死锁事，我们设置的时间过长会导致某些在线的系统无法接受，如果时间过短，死锁很快就会解开，但是如果不是死锁呢，只是简单的等待释放，这样会导致误伤。
正常情况下，我们会采用第二种策略，主动死锁检测，但是如果并发线程过多，会导致检索的线程过多，非常消耗cpu的资源。
解决办法
1、如果你能确保这个业务一定不会出现死锁，可以临时把死锁检测关闭掉。一般不建议采用
2、控制并发度，对应相同行的更新，在进入引擎之前排队。这样在InnoDB内部就不会有大量的死锁检测工作了。
3、将热更新的行数据拆分成逻辑上的多行来减少锁冲突，但是业务复杂度可能会大大提高

注：MySQL行锁，锁的是索引，因为InnnoDB引擎的原因，不会没有索引的。

产生死锁的原因

• 竞争不可剥夺的资源（例如：系统中只有一台打印机，可供进程P1使用，假定P1已占用了打印机，若P2继续要求打印机打印将阻塞）
• 产生死锁中的竞争资源另外一种资源指的是竞争临时资源（临时资源包括硬件中断、信号、消息、缓冲区内的消息等），通常消息通信顺序进行不当，则会产生死锁
• 进程推进的顺序非法，如上面的例子，事务A在等待事务B释放id=2的行锁，而事务B在等待事务A释放id=1的行锁
  必要条件
• 互斥条件：进程要求对所分配的资源进行排它性控制，即在一段时间内某资源仅为一进程所占用。
• 请求和保持条件：当进程因请求资源而阻塞时，对已获得的资源保持不放。
• 不剥夺条件：进程已获得的资源在未使用完之前，不能剥夺，只能在使用完时由自己释放。
• 循环等待：在发生死锁时，必然存在一个进程–资源的环形链。
  预防死锁：
• 资源一次性分配：一次性分配所有资源，这样就不会再有请求了：（破坏请求条件）
• 只要有一个资源得不到分配，也不给这个进程分配其他的资源：（破坏请保持条件）
• 可剥夺资源：即当某进程获得了部分资源，但得不到其它资源，则释放已占有的资源（破坏不可剥夺条件）
• 资源有序分配法：系统给每类资源赋予一个编号，每一个进程按编号递增的顺序请求资源，释放则相反（破坏环路等待条件）