mysql lock

Lost updates, dirty reads, non-repeatable reads, phantom reads;
Lost update means: in transaction A and transaction B, suppose transaction A made an update and committed it, but transaction B did not notice what transaction A did, so transaction B still executed as usual, so transaction B lost updates;
 

 

 
How to avoid this problem?
We can solve this problem through optimistic locking. Before transaction A performs the update operation, it can first perform query judgment, select table set amout = 1100 where id = xxx and amount = 1000; plus an amount judgment, if the previous data is changed If there is no modification, the execution succeeds; otherwise, the execution fails and rolls back;
Here we will talk about the concept and difference between optimistic locking and pessimistic locking by the way;
    Pessimistic lock: As the name suggests, it is very pessimistic. Every time I go to get data, I think the data has been modified, so it will be locked every time. Pessimistic lock is generally used when the conflict rate is relatively high.
    Optimistic locking: It is very optimistic, thinking that others will not modify it, so it will not be locked, but when updating, it will judge whether others have updated the data during this period. If it is updated, the data will be rolled back, optimistic When the lock user writes less and reads more, the map collision rarely occurs and the overhead of locking is reduced; while the pessimistic lock is used when the conflict rate is relatively high to ensure the security of the database. If optimistic locking is added, Constantly rolling back, but reducing performance;
    When we use optimistic locking, we will use version locking and update the status of money to achieve it;
    Forehead. . . Well, let's move on to the question of reading. . . Just off topic. . . .
Dirty read:
    Dirty read is the opposite of the previous one, that is, between transaction A and transaction B, transaction A performs an operation, and transaction B queries your operation. However, at this time, transaction A is rolled back again, which is a painful operation. , so the real data is actually unchanged, and the data queried by transaction B is actually dirty data;

 

 
Phantom reading: hallucinations occur; that is, transaction A queries that there is no data, and at this time, transaction B updates the data, and when transaction A inserts data, it finds that there is a conflict. Data, when inserting data, it is found that the data conflicts, just like hallucinations; this is phantom reading;
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324632311&siteId=291194637