场景描述

14点~15点之间数据库出现大量行锁冲突，内核中大量update/insert会话在等待行锁释放，导致CPU使用率达到70%左右，数据库操作变慢。

查看CES指标行锁等待个数、MDL锁数量，下图仅供参考：

发生死锁的表：

********* 1. row *********
Table: table_test Create Table: CREATE TABLE table_test(
...
CONSTRAINT act_fk_exe_parent FOREIGN KEY (parent_id_) REFERENCES act_ru_execution (id_) ON DELETE CASCADE,
CONSTRAINT act_fk_exe_procdef FOREIGN KEY (proc_def_id_) REFERENCES act_re_procdef (id_),
CONSTRAINT act_fk_exe_procinst FOREIGN KEY (proc_inst_id_) REFERENCES act_ru_execution (id_) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT act_fk_exe_super FOREIGN KEY (super_exec_) REFERENCES act_ru_execution (id_) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

原因分析

部分表发生死锁，导致CPU一定幅度抬升。
死锁的表中有大量的外键，这些表的记录在更新时，不仅需要获取本表的行锁，还需要检查外键关联表的记录，获取相应锁。高并发情况下，比普通表更容易锁冲突或死锁，详解官方文档。
当MySQL检查到死锁的表时，会进行事务的回滚。其影响范围不仅是某个表，还会影响外键所在的表，最终导致数据库相关操作变慢。

解决方案

建议排查并优化死锁表相关的业务，业务上合理使用外键，避免更新冲突，避免产生死锁。

父主题： 性能资源类

同意关联代理商云淘科技，购买华为云产品更优惠（QQ 78315851）

内容没看懂？ 不太想学习？想快速解决？ 有偿解决： 联系专家