mysql死锁排查

应用访问Mysql数据库的时候，如果业务逻辑写的不严谨，不规范，就会发生死锁，如果此业务逻辑调用并发高，则业务日志经常会有死锁的错误日志产生。应用发生死锁，于是dba就去排查，看数据库的错误日志，就会发现，没有任何关于死锁的日志告警，这是因为默认配置情况下，数据库是不打印任何死锁的日志信息。

 那如何去排查应用的死锁问题呢，下面给大家详细介绍。先看看关于死锁信息打印的参数，默认是关闭

mysql> show variables like 'innodb_print_all_deadlocks';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| innodb_print_all_deadlocks | OFF   |
+----------------------------+-------+
1 row in set (0.01 sec)

想要在发生死锁的情况打印相关信息，需要开启这个参数

mysql> set global innodb_print_all_deadlocks=on;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'innodb_print_all_deadlocks';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| innodb_print_all_deadlocks | ON    |
+----------------------------+-------+
1 row in set (0.01 sec)

开启之后，下面模拟一个死锁的场景
开启会话1，执行如下语句

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> update t_test10 set name='test33' where id='1';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 0

mysql> update t_test10 set name='testkii' where id='4';
Query OK, 0 rows affected (5.38 sec)
Rows matched: 1  Changed: 0  Warnings: 0

开启会话2，执行如下语句

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> update t_test10 set name='testkii' where id='4';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 0

mysql> update t_test10 set name='test33' where id='1';
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

在会话2里，可以很明显的看到，mysql检测到Deadlock，并回滚了会话2的sql，让会话的事物能继续进行。那mysql怎么选择回滚那个会话呢，主要从回滚代价上去考虑的，谁的锁持有的少，则回滚对应的会话事物。下面看看数据库的死锁详细信息看看


在数据库告警日志可以找死锁发生时，对应的sql语句和应用访问用户，应用访问IP，有了这些只会，再去找开发，看对应的代码逻辑，就能很容易的定位到问题，并解决。

给大家举一个实际的业务场景，在电商场景，下单的时候，会有主订单表和扩展订单表，如果有一个代码接口更新订单表顺序为（主订单表，扩展订单表），而另一个代码接口更新订单表顺序为（扩展订单表，主订单表），在并发高的时候，就很容易就发送死锁。

参考链接 ：

mysql死锁排查 ：https://mp.weixin.qq.com/s/mrk3mcXpkNSdvvtIIrbSHA