mysql死锁处理方法(mysql死锁产生原因及解决办法)

导语：熟读此文，再也不用担心Mysql死锁了

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

mysql> show variables like &39;;+----------------------------+-------+| 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 &39;;+----------------------------+-------+| 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=&39; where id=&39;;Query OK, 0 rows affected (0.00 sec)Rows matched: 1 Changed: 0 Warnings: 0mysql> update t_test10 set name=&39; where id=&39;;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=&39; where id=&39;;Query OK, 0 rows affected (0.00 sec)Rows matched: 1 Changed: 0 Warnings: 0mysql> update t_test10 set name=&39; where id=&39;;ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

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

在数据库告警日志可以找死锁发生时，对应的sql语句和应用访问用户，应用访问IP，有了这些只会，再去找开发，看对应的代码逻辑，就能很容易的定位到问题，并解决。给大家举一个实际的业务场景，在电商场景，下单的时候，会有主订单表和扩展订单表，如果有一个代码接口更新订单表顺序为（主订单表，扩展订单表），而另一个代码接口更新订单表顺序为（扩展订单表，主订单表），在并发高的时候，就很容易就发送死锁。

喜欢我的小伙伴，可以在下方留言和关注。

本文内容由快快网络小玥创作整理编辑！