面对数据库死锁差点跪！
码上实战
理论实践相结合，做个好好学习的宝宝！^_^
关注
数据库死锁这个问题不知道你有没有遇到过呢？一旦遇到该如何排查问题呢？
环境: MySQL 5.7.25 引擎 InnoDB
如果你的系统日志突然报这种错误，就问你慌不慌？心想：MD，之前遇到过，但完全不记得该怎么办了！！！完了完了！被领导知道我解决不了这个问题，不会被开除吧！
2019-10-23 13:07:17.144 ERROR nested exception is org.springframework.dao.DeadlockLoserDataAccessException:### Error updating database. Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction### The error may involve com.x.x.mapper.XMapper.update-Inline### The error occurred while setting parameters### SQL: UPDATE tb_a SET start_time = ?, end_time = ? WHERE id = ?### Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transactioncom.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
想我一个堂堂工作几年的开发者，挂在这个地方，那岂不是很没面子啊！操练起来。
什么是死锁？
当多个进程访问同一数据库时，其中每个进程拥有的锁都是其他进程所需的，由此造成每个进程都无法继续下去。简单的说，进程A等待进程B释放他的资源，B又等待A释放他的资源，这样就互相等待就形成死锁。
查看数据库基本信息
查看数据库版本：select version();
事务隔离级别查询方法：select @@tx_isolation
通过命令show engines查看一下InnoDB的特点
| Engine | Support | Comment |
|---|---|---|
| InnoDB | DEFAULT | Supports transactions, row-level locking, and foreign keys |
| MyISAM | YES | MyISAM storage engine |
InnoDB支持事务，行级锁及外键。
我们平时遇到的就是多个事务之间行级锁导致的。
分析
业务日志中的记录太过简单，只知道哪个方法的事务发生了死锁，没有多余的信息，所以我们要到数据库中寻找更多的有用信息，通过命令 show engine Innodb status 查看:
------------------------LATEST DETECTED DEADLOCK------------------------2019-10-23 16:46:42 0x7fa919415700# 事务1*** (1) TRANSACTION:TRANSACTION 21010939, ACTIVE 1 sec starting index readmysql tables in use 1, locked 1LOCK WAIT 4 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1MySQL thread id 255825, OS thread handle 140363604055808, query id 179915249 localhost 127.0.0.1 root updatingUPDATE tb_b SET end_time = 1571821300000 WHERE id = 18199# 等待b表的X锁*** (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 1924 page no 284 n bits 80 index PRIMARY of table `dmeeting`.`tb_b` trx id 21010939 lock_mode X locks rec but not gap waitingRecord lock, heap no 9 PHYSICAL RECORD: n_fields 26; compact format; info bits 0# 事务2*** (2) TRANSACTION:TRANSACTION 21010938, ACTIVE 1 sec starting index readmysql tables in use 1, locked 14 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1MySQL thread id 255826, OS thread handle 140364249913088, query id 179915304 localhost 127.0.0.1 root updatingUPDATE tb_a SET actual_start_time = 1571820362678, actual_end_time = null WHERE id = 14266# 持有b表的X锁*** (2) HOLDS THE LOCK(S):RECORD LOCKS space id 1924 page no 284 n bits 80 index PRIMARY of table `dmeeting`.`tb_b` trx id 21010938 lock_mode X locks rec but not gapRecord lock, heap no 9 PHYSICAL RECORD: n_fields 26; compact format; info bits 0# 等待a表的X锁*** (2) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 1934 page no 324 n bits 112 index PRIMARY of table `dmeeting`.`tb_a` trx id 21010938 lock_mode X locks rec but not gap waitingRecord lock, heap no 45 PHYSICAL RECORD: n_fields 38; compact format; info bits 0# 回滚事务2*** WE ROLL BACK TRANSACTION (2)
分析上面的死锁日志，能够得出以下死锁场景：
| 时间序列 | 事务1 | 事务2 |
|---|---|---|
| 1 | START TRANSACTION; | START TRANSACTION; |
| 2 | ||
| 3 | UPDATE tb_b SET start_time = ? WHERE id = 18199 持有b表行级X锁 | |
| 4 | UPDATE tb_b SET end_time = ? WHERE id = 18199 申请b表行级X锁 | |
| 5 | UPDATE tb_a SET actual_start_time = ?, actual_end_time = ? WHERE id = 14266 申请a表行级X锁 | |
| 6 | Deadlock found when trying to get lock; try restarting transaction(Rollback) |
仅仅根据死锁日志分析，我是百思不得其解，在事务1中并没有显示持有a表的X锁，那么这是怎么造成死锁的呢！我就是个愣头青，就知道面对死锁日志想来想去，浪费了时间，幸得身旁有大神指点，去看看业务系统中这两个事务代码，才发现原来事务1中在时间序列2时对a表进行了更新操作，已经持有了a表的行级锁！这下就完全明白了，两个事务互相等待对方释放锁，这就是造成死锁的原因。
原因知道了，那就通过更改代码，让两个事务里表更新的顺序一致即可。
总结排查步骤
通过业务系统日志快速定位到发生死锁的代码块 查看InnoDB的死锁日志，找出各个事务对应的代码块 通过死锁日志和业务代码推测画出死锁的事务发生场景
降低发生死锁的概率
避免大事务，可以拆分成多个小事务，因为大事务耗时长，与其他事务发生的概率就大。 多个事务操作相同的一些资源，尽量保持顺序一致。 更新语句尽量只更新必要的字段，内容相同的字段不要更新。
记录完整的死锁日志
show engine innodb status 时，显示的信息不全。
这是mysql客户端的一个bug：BUG#19825，交互式客户端限制了输出信息最大为 64KB，因此更多的信息无法显示。
但我们可以通过开启锁监控来查看完整的日志，方式如下：
# 建议排查问题后关闭，15秒输出一次，会导致日志越来越大-- 开启标准监控 开ON/关OFFset GLOBAL innodb_status_output=ON;-- 开启锁监控 开ON/关OFFset GLOBAL innodb_status_output_locks=ON;
也可以通过一个专门用于记录死锁日志的参数：
set GLOBAL innodb_print_all_deadlocks=ON;内容一般输出到 mysql error log 里，查看日志位置：select @@log_error
了解一下锁的概念或许对大家更有帮助：
锁的种类
锁级别
行级锁（引擎INNODB）：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
表级锁（引擎MyISAM）：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。
锁类型
next KeyLocks锁，同时锁住记录(数据)，并且锁住记录前面的Gap
Gap锁，不锁记录，仅仅记录前面的Gap
Recordlock锁（锁数据，不锁Gap）
所以其实 Next-KeyLocks=Gap锁+ Recordlock锁
锁模式
首先我们要知道两种最容易理解的锁模式，读加共享锁，写加排它锁。
LOCK_S（读锁，共享锁） LOCK_X（写锁，排它锁）
还有：
LOCK_IS（读意向锁）
LOCK_IX（写意向锁）
LOCK_AUTO_INC (自增锁)
更加详细的介绍可以去看看这篇文章：
https://www.aneasystone.com/archives/2018/04/solving-dead-locks-four.html http://www.throwable.club/2019/05/11/mysql-deadlock-troubleshoot-1st/#%E5%AF%BC%E8%87%B4%E6%AD%BB%E9%94%81%E7%9A%84%E5%8E%9F%E5%9B%A0