Share a method to solve the MySQL deadlock problem

Share a method to solve the MySQL deadlock problem

1. Environment

• CentOS, MySQL 5.6.21-70, JPA

• Problem scenario: The system has a scheduled batch update data status operation, updating thousands of records each time, and the total number of records in the table is about 5 million.

2. Error log

2017-2-25 17:38:41 org.hibernate.util.JDBCExceptionReporter logExceptions
严重: Lock wait timeout exceeded; try restarting transaction
2017-2-25 17:39:05 org.hibernate.util.JDBCExceptionReporter logExceptions
警告: SQL Error: 1213, SQLState: 40001
2017-2-25 17:39:05 org.hibernate.util.JDBCExceptionReporter logExceptions
严重: Deadlock found when trying to get lock; try restarting transaction

3. Troubleshooting

Check InnoDB status for locks
mysql> SHOW ENGINE InnoDB STATUS;

Check MySQL open tables
mysql> SHOW OPEN TABLES WHERE In_use > 0;

Check pending InnoDB transactions
mysql> SELECT * FROM `information_schema`.`innodb_trx` ORDER BY `trx_started`; 

Check lock dependency - what blocks what
mysql> SELECT * FROM `information_schema`.`innodb_locks`;

After troubleshooting, it was found that problems occurred when executing statements similar to this:

update t_task_tel set state='iok', update_date='2017-02-27 11:03:02' where tel_id=66042 and task_id=350199;

4. Analysis

After searching for relevant information, I found that MySQL InnoDB does not necessarily all have row-level locks.

Relevant reference material fragments are as follows:

Lock selection
1), if the update condition does not go through the index, for example, execute "update from t1 set v2=0 where v2=5;", At this time, a full table scan will be performed. When scanning the table, any other update operations must be prevented, so it is upgraded to a table lock.
2) If the update condition is an index field, but it is not a unique index (including the primary key index), for example, if you execute "update from t1 set v2=0 where v1=9;"

then the update will Use Next-Key Lock. Reasons for using Next-Key Lock:
a), first ensure that an exclusive lock is added to the records that meet the conditions, which will lock the value of the current non-unique index and the corresponding primary key index;
b), and also It is guaranteed that new data cannot be inserted into the locked interval.
3) If the update condition is a unique index, use Record Lock.

InnoDB finds the corresponding record based on the unique index, and adds the record lock to the primary key index value and the unique index value. But do not use Gap Lock (gap lock).
Since InnoDB defaults to Row-Level Lock, MySQL will execute Row lock (only lock the selected data) only if the primary key is "clearly" specified. Otherwise, MySQL will execute Table Lock (lock the entire data). The form is locked).

According to the analysis conclusion, it is guessed that the reason is that tel_id and task_id did not establish UNIQUE (unique index) in the Where condition when updating the _task_tel table;

5. Solution

Based on this analysis, try to solve the problem by establishing UNIQUE (unique index) through the two fields of tel_id and task_id. (You can also query it first and then update it based on the primary key ID, so that the large amount of data in the table will not affect online business).

After solving this problem, the problem has not recurred.

If your problem is similar to what I encountered, you can try to solve it accordingly.