mysql死锁发生和排查

mysql死锁排查

死锁产生四个必要条件

• （1） 互斥条件：一个资源每次只能被一个进程使用。
• （2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
• （3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
• （4）循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

发现死锁：

• 可以用show engine innodb status;命令来查看最近的死锁语句
• 查看binlog日志：地址：show variables like '%log_bin%';
• 转化binlog日志为sql语句：mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000011 -d tide > tide.sql

#从下面的日志可以看出，有两个事务在相互争夺资源
第一：数据库记录X锁，符合互斥条件
第二：在程序获得锁之后不会释放，而会请求并保持，符合请求并保持条件
第三：不剥夺
第四：程序中请求的资源顺序不同，导致两个事务形成循环等待

出现死锁后，mysql自动会将影响较小的那个事务进行回滚来释放资源，另一个事务便可以成功获得资源。

LATEST DETECTED DEADLOCK
------------------------
2020-03-14 13:30:01 0x7f967c9e3700
*** (1) TRANSACTION:
TRANSACTION 5416193, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 13087432, OS thread handle 140284707096320
UPDATE
        TP_CUSTOMER_ACCOUNT
        SET
        withdrawable_balance = withdrawable_balance - 0.39
        WHERE
        CUSTOMER_ACCOUNT_ID = 'xxx'
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 40 page no 7 n bits 152 index PRIMARY of table 
*** (2) TRANSACTION:
TRANSACTION 5416190, ACTIVE 0 sec starting index read
UPDATE
        TP_CUSTOMER_ACCOUNT
        SET
        withdrawable_balance = withdrawable_balance + 0.13
        WHERE
        CUSTOMER_ACCOUNT_ID = 'xxx'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 40 page no 7 n bits 152 index PRIMARY of table `tp_customer_account` 
Record lock, heap no 20 PHYSICAL RECORD: n_fields 18; compact format; info bits 0

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 40 page no 9 n bits 232 index uniq_customer_account_id of table`tp_customer_account` trx id 5416190 lock_mode X locks rec but not gap waiting
*** WE ROLL BACK TRANSACTION (1)
------------
TRANSACTIONS
------------
Trx id counter 5437557
----------------------------
END OF INNODB MONITOR OUTPUT
============================