mysql死锁场景整理

本文死锁场景皆为工作中遇到（或同事遇到）并解决的死锁场景，写这篇文章的目的是整理和分享，欢迎指正和补充，本文死锁场景包括：

注 ：以下场景隔离级别均为默认的Repeatable Read；

前提 ：表 t_user 的 uid 字段创建了唯一索引，并拥有可更新字段age。

场景复现 ：

相应业务案例和解决方案 ：

该场景常见于事务中存在for循环更新某条记录的情况，死锁日志显示 lock_mode X locks rec but not gap waiting （即行锁而非间隙锁），解决方案：

表结构 :

场景复现 ：

首先查询表中目前存在的记录：

执行两个事务的 *** 作：

死锁原因分析 ：

解决方案 ：

t_user结构改造为：

场景复现 *** 作（几率不高） ：

假设存在以下数据 ：

死锁分析 ：

事务1 ：

① 锁住zone_id=1对应的间隙锁: zoneId in (1,2)

② 锁住索引zone_id=1对应的主键索引行锁id = [1,2]

③ 锁住uid=1对应的间隙锁: uid in (1, 2)

④ 锁住uid=1对应的主键索引行锁: id = [1, 3]

事务2 ：

① 锁住zone_id=2对应的间隙锁: zoneId in (1,2)

② 锁住索引zone_id=2对应的主键索引行锁id = [3,4]

③ 锁住uid=2对应的间隙锁: uid in (1, 2)

④ 锁住uid=2对应的主键索引行锁: id = [2, 4]

解决方案 ：创建联合索引，使执行计划只会用到一个索引。

测试表结构 :

场景复现 *** 作 ：

解决办法：尽量避免这种插入又回滚的场景。

避免死锁的原则：

第一步，查出已锁的进程

查看正在锁的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS

``

查看等待锁的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS

``

INNODB_TRX表主要是包含了正在InnoDB引擎中执行的所有事务的信息，包括waiting for a lock和running的事务

select * from information_schema.innodb_trx

``

第二步，kill进程

show engin innodb status //最后一次死锁信息及sql

show open tables where in_use >0 //查看锁表

1、查询是否锁表

show OPEN TABLES where In_use >0

查询到相对应的进程 === 然后 killid

2、查询进程

show processlist

补充：

查看正在锁的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS

查看等待锁的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS

---