MySql六：行锁

基本概念：对数据库中表的行记录的锁，同一张表上任何一个时刻只能有一个更新在执行，即对同一行的数据不能有多个事务同时对它进行操作。行锁是InnoDB引擎所特有的。

两阶段锁协议：在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。
这就启示我们当执行某一事务时要把造成锁冲突和影响并发度最大的锁尽量往后放，否则可能会影响正常的工作流程。

死锁：当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁
如A事务开始执行对id=1这一行数据的修改，B事务开始执行对id=2这一行数据的修改，但都没有提交。此时A和B事务还要分别对id=2和id=1所在的行进行修改，但由于行锁的存在导致两者都在等待对方资源的释放形成依赖进入了死锁状态。
进入死锁状态后有两种策略：
一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。
另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

对于第一种策略设置的等待时间既不能过长也不能过短，如果过长就会导致长时间的业务停摆，如果过短则容易把简单的锁等待误判为死锁导致误伤。因此适合用第二种方法，但是第二种方法也有可能造成额外的负担：如果所有的事务都更新同一行，每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是 O(n) 的操作。假设有 1000 个并发线程要同时更新同一行，那么死锁检测操作就是 100 万这个量级的。虽然最终检测的结果是没有死锁，但是这期间要消耗大量的 CPU 资源。

解决上述问题最主要的策略是控制并发度：控制访问相同资源的并发事务量。