What is the locking mechanism of mysql transaction serialization

what is the locking mechanism of mysql transaction serialization isolation level
Open transactions in both An and B clients, if
1 if A transaction deletes a record (), B transaction cannot read deleted and uncommitted transactions in A transaction not yet committed, this is because A transaction adds a write lock
2 if A transaction inserts a piece of data (if ID is 4), then in B transaction, ID = 1,2,3 can be read normally, but
select * from account where id < = 3;
will wait. I don"t quite understand. I hope you won"t hesitate to give me your advice and thank you

.

reference:
1 MySQL high performance mentions that serialization locks every row of data read (which means partial lock, but does not lock the table)
2 https://tech.meituan.com/inno.
mentioned here: serial read (Serializable): is fully serialized, and table-level shared locks need to be obtained for each read. Both read and write block each other
which means locking the table, whether it is locking the table or locking some records
3 Why do shared locks block each other


isolation mechanism is complicated, and different databases are not consistent. Your problem is based on MySQL Innodb,. My understanding is this:
Serializable isolation locks the record every time it accesses the record (no matter reading or writing), so it leads to the problem you mentioned. Although you add the condition id < = 3, you still need to traverse to each record to give the select result, so it will still be locked.?.

this level of isolation is rarely used in real projects (I've never used it in real projects). Because of the low concurrency performance and easy deadlock, the default REPEATABLE READ or READ COMMITTED is the most commonly used.

Menu