应用访问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: 0mysql> 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: 0mysql> 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，有了这些只会，再去找开发，看对应的代码逻辑，就能很容易的定位到问题，并解决。
)
