标签:image 状态 http update 如何 阶段 img sql width
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、将热更新的行数据拆分成逻辑上的多行来减少锁冲突,但是业务复杂度可能会大大提高。
标签:image 状态 http update 如何 阶段 img sql width
原文地址:https://www.cnblogs.com/lakeslove/p/12240333.html