MySQL的行锁在引擎层由各个引擎自己实现的，但并不是所有的引擎都支持行锁。
不支持行锁意味着并发控制只能使用表锁，对于这种引擎的表，同一张表任何时刻只能有一个更新在执行，这会影响到业务并发度。
InnoDB引擎下的事务中，行锁是需要的时候才加上的，但并不是不需要了立刻释放，而是要等到事务结束时（commit时候）才释放，成为两阶段锁协议。
当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。
事务A在等待事务B释放id=2的行锁，事务B在等待事务释放id=1的行锁，相互等待对方释放资源，就进入了死锁的状态。
出现了死锁后，有两种策略：
- 策略1，直接进入等待，直至超时。这个超时时间可以通过参数
innodb_lock_wait_timeout来设置 - 策略2，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数
innodb_deadlock_detect设置为on，表示开启这个逻辑
两种策略都有优缺点，所以需要尽量避免死锁。
如果一个事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁的申请时机尽量往后放。