Scenario analysis of deadlock during MySQL insert

Case a ：
There is a watch A, To update , If the number of affected rows is 0, execute INSERT insert data . Very common scenes , It has also been running for a long time in production , No problem . But there was a deadlock during the pressure test in the test environment ,Deadlock found when trying to get lock; try restarting transaction

Because of mysql Unfamiliar with locks , Why? insert It's also deadlocked , Not usually in update Will it be deadlocked when you are ？ I'm curious , So I began to look for the reason …

mysql The lock is related to the isolation level of the database , Different isolation levels , Locks are also different , As long as it is to solve similar dirty reading 、 Fantasy reading 、 Repeatable questions .
select @@tx_isolation; – Check the isolation level

The isolation level is RR（ Repeatable ）, We know , Under this isolation level , In order to solve the problem of unreal reading , There will be clearance locks and Next-key lock( Row lock + Clearance lock ), That is to say update、delete After the statement, a gap lock and Next-key lock, If in concurrency , There are two transactions that are executed in advance UPDATE sentence （ Each holds gap lock）, When INSERT when , First obtain the insertion intention lock on the insertion gap , There is a conflict due to the gap between the inserted data , So they will wait for each other to obtain the insert intent lock , That is, they compete with each other , It will eventually lead to a deadlock on one side .

This also explains why there are deadlocks in the test environment .
solve ：

1. Do not use transactions , I.e. no transaction execution , However, if an exception occurs, the data will be inconsistent .
2. Adjust the transaction isolation level to read commit,RC Level does not produce gap lock

Because we all know the importance of affairs , So choose the second way , Change the isolation level to RC. Our production environment is generally at this level , So it also explains why this problem does not occur in production .

The transaction isolation level can be adjusted through spring The declarative transaction mode , Through annotation @Transactional

@Transactional(rollbackFor = Exception.class, isolation = Isolation.READ_COMMITTED)
public void calculationEntry(List<CampaignFeedback> campaignFeedbackList, String groovyScript) {
    
    //todo
}

Pressure test again , Deadlock problems no longer occur .

Case 2 ：
Because of business needs , Often update or write to a table , I don't want to query whether it exists before inserting it every time , So we used mysql Of replace into To achieve .
replace into The syntax is if there is a primary key or a unique index in the table , It will judge whether it exists according to this dimension , If it exists, it will delete stay insert, That is, it will operate in two separate steps , There is no guarantee of atomicity .

I think it is very convenient after I start using it , After all, you don't have to check it again ,mysql Automatically helped us complete . But when it comes to pressure measurement , The deadlock has reappeared ......

Because of the previous experience , So it's not a problem , So it was changed as before . I ran in the test environment several times without any problem , I think it's the same problem , So it went online .

After the launch , When I go to verify this function , fuck ... The deadlock problem appeared before my eyes again .

I'm in a panic , Why not this time , Is my code covered ？ Look over git The submission record of does not ..

So we went to consult DBA, He said replace into This is not recommended , Because in a large concurrency environment , There must be a deadlock . We are advised to use insert into … values … on duplicate key update … To replace

So press DBA It is suggested to change , After going online again , No matter how concurrent, there will be no deadlock .
Cause analysis , If you use replace into mysql On by default Gap lock and Next-key lock, So even adding transaction configuration does not work .

The last attached insert into … on duplicate key update Introduce ：
grammar ：
INSERT INTO tablename (field1,field2, field3, …) VALUES(value1, value2, value3, …) ON DUPLICATE KEY UPDATE field1=value1,field2=value2, field3=value3, …;

You can also use the following methods （ This supports batch insertion ）
INSERT INTO TABLE (a,b,c) VALUES
(1,2,3),
(2,5,7),
(3,3,6),
(4,8,2)
ON DUPLICATE KEY UPDATE a=VALUES(a), b=VALUES(b),c=VALUES（c）;