更新时间:2024-12-16 GMT+08:00
业务死锁导致响应变慢
场景描述
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检查到死锁的表时,会进行事务的回滚。其影响范围不仅是某个表,还会影响外键所在的表,最终导致数据库相关操作变慢。
解决方案
建议排查并优化死锁表相关的业务,业务上合理使用外键,避免更新冲突,避免产生死锁。
父主题: 性能资源类