07 | 行锁功过：怎么减少行锁对性能的影响？

 

 

mysql5.7出现死锁时，导致死锁的那个事务会回滚，被死锁的事务正常获取锁。

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

查看该选项：

show variables like '%deadlock%';

 

+----------------------------+-------+

| Variable_name              | Value |

+----------------------------+-------+

| innodb_deadlock_detect     | ON    |

| innodb_print_all_deadlocks | OFF   |

+----------------------------+-------+

update T set c = 1 where c = 11;

和

update T set c = 222 where c = 22;

会产生锁冲突，不理解原因。

 

假设有 1000 个并发线程要同时更新同一行，那么死锁检测操作就是 100 万这个量级的。

虽然最终检测的结果是没有死锁，但是这期间要消耗大量的 CPU 资源。

因此，你就会看到 CPU 利用率很高，但是每秒却执行不了几个事务。

 

总结：
两阶段锁：在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放， 而是要等到事务结束时才释放。
建议：如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。
死锁：当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态。
解决方案：
1、通过参数 innodb_lock_wait_timeout 根据实际业务场景来设置超时时间，InnoDB引擎默认值是50s。
2、发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑（默认是开启状态）。
如何解决热点行更新导致的性能问题？
1、如果你能确保这个业务一定不会出现死锁，可以临时把死锁检测关闭掉。一般不建议采用
2、控制并发度，对应相同行的更新，在进入引擎之前排队。这样在InnoDB内部就不会有大量的死锁检测工作了。
3、将热更新的行数据拆分成逻辑上的多行来减少锁冲突，但是业务复杂度可能会大大提高。