MySQL default transaction isolation level and row lock

Review of isolation level

The isolation level of database transactions mentioned above , In retrospect ：

1、READ-UNCOMMITTED -> Read uncommitted ： There is no insurance , Dirty reading 、 It can't be read repeatedly , Fantasy reading , It could happen
2、READ_COMMITTED -> Read the submission ： Only submitted data can be read , No dirty reading
3、REPEATABLE_READ -> Repeatable ： Dirty reading and unrepeatable reading will not occur , There may be unreal reading ,mysql non-existent ,Innodb The storage engine solves the problem of unreal reading through multi version concurrent control .
4、SERIALIZABLE -> Serialization ： If serialization is performed , Line up one by one , There will be no data confusion and inconsistency , But the cost is low efficiency .

mysql innoDB Default isolation level -> REPEATABLE_READ: Repeatable
That is, the uncommitted data of other transactions will not be read during the current transaction , And the newly submitted data will not be read

verification

Let's verify , Verification step sorting ：
1. Open two mysql link A and B( Not two execution windows ), link A and B Open a transaction respectively , The method is execution :BEGIN;
2. link A According to the ID Update a piece of data without execution COMMIT Submit operation , link B Query the data in , Verify whether there are dirty reads
3. link A According to the ID Update a piece of data to execute COMMIT Submit operation , link B Don't execute COMMIT When querying this data , Verify that there is no unreadable
4. New link C Insert a piece of data in , New link D Query the data , Verify whether there is unreal reading

The test table :
CREATE TABLE t_test_batch (
t_id varchar(32) CHARACTER SET utf8 NOT NULL DEFAULT ‘’,
code varchar(32) CHARACTER SET utf8 DEFAULT NULL COMMENT ‘ Code ’,
name varchar(100) CHARACTER SET utf8 DEFAULT NULL COMMENT ‘ name ’,
PRIMARY KEY (t_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT=‘ Test the transaction isolation level ’;

Create a piece of data , Field name The value is 444：

Start validation

1. Open a new link A And open the business , Perform modifications to the sample data

2. Open a new link B And open the business , Perform a query on the sample data , Did not read link A Modification of data in transactions

3. link A In the implementation of COMMIT Commit transaction , Execute the link again B Query in , The return result does not change
   

4. link B In the implementation of COMMIT Commit transaction , Execute the link again B Query in , Return result changes , Read the link A Modification of transactions

5. link D Open transaction query code='AaA3’ data , No data . Link at this time C Insert code='AaA3’ The data of , link D Query again , Still can't find , link D Commit the current transaction , You can find the data by querying again . The screenshot here ignores ...

Conclusion

Conclusion ：mysql The default transaction isolation level can ensure that dirty reads do not occur in transactions 、 No repeated reading or phantom reading . Business A Modified or added data , Business B Transactions can only be read after committing A Modification or addition of .

Let's go

Here's a question , If the transaction A and B Modify the same data at the same time , What will happen ？ Continue to verify , Open two transactions , At the same time, execute the following update operation .

link A
BEGIN;

UPDATE t_test_batch t SET t.name=‘0.0.0’ WHERE t.t_id=‘0009c52726154074a650444a15f910ad’;

link B
BEGIN;

UPDATE t_test_batch t SET t.name=‘11111’ WHERE t.t_id=‘0009c52726154074a650444a15f910ad’;

Results found ,A It's no problem to execute first , Without submission ,B Stuck after execution , All the way around , It seems to be locked .

Check whether there is currently a lock (information_schema.INNODB_LOCKS), Found two records , Show 0009c52726154074a650444a15f910ad This record has two X lock , And the lock is ok .

S Lock and X lock

Mysql X lock ： Exclusive lock - Write lock ,mysql Modifying data will lock the data to ensure data consistency , The transaction modification data will be locked automatically . Business A Lock a piece of data modification , The transaction B、 Business C To modify this data , stay A When no transaction is committed , You can only try to lock this data , Then queue up and fall into waiting . Exclusive lock , Exclusion does not allow other matters to interfere .

Mysql S lock ： Said exclusive lock , It is necessary to mention the shared lock, that is S lock - Read the lock . To ensure that transactions read data , This data will not be modified by other transactions , The current transaction can add S lock , Multiple transactions can be locked at the same time , One layer at a time S lock . The purpose of this is ： Now I just want to read data quietly , If you want to modify the data, wait until I'm finished ！
meanwhile S Locks have another function , If someone is modifying this data , Currently, when reading this data, if you try to add a shared lock, you will also fall into waiting . Read without sharing lock , Adding a shared lock may wait ！

When adding, deleting or modifying, it will automatically add X lock
Query is unlocked by default , You can add it manually S Lock and X lock
The way is
Add S lock : select * from table_xxx lock in share mode;
Add X lock : select * from table_xxx for update;

Optimistic lock and pessimistic lock

The above states mysql Two kinds of locks , Both locks are pessimistic , It means whether you believe it or not , Anyway, I think it's bound to conflict with others , I'll lock it first, I'll use it first .

There is also an optimistic lock , That is, do not lock directly , I'm optimistic that no one is competing with me at present , Only when submitting the modification can we judge whether there is a conflict by the version number . When it is found that the version number in the current data database is inconsistent with the currently used version number , Think the data has been modified , give up .

Pessimistic lock database has been implemented , Optimistic lock needs to be realized by ourselves .

remaining problems

The above lock , Lock type lock_mode You can see both of them record, Instant lock .

Another kind of lock is table lock . Baidu found that it was insert Lock the watch ,update Lock line , Or what goes through the primary key index lock line , Otherwise lock the watch , The actual test is not like this ..

Various attempts have not found how to appear for the time being information_schema.INNODB_LOCKS In the table lock_type For the wrong record, Want to have a watch lock , I haven't succeeded yet ~

However, you can manually lock the table ：LOCK TABLES … WRITE/READ
Such as LOCK TABLES t_test_batch READ, During this period, all transaction execution, modification and addition will fall into wait .
Use UNLOCK TABLES Unlock , I don't know the difference between this and the concept of row lock and table lock , Here to learn more .