1. About dirty reads, phantom reads and non-repeatable reads

Dirty read : A transaction A reads the uncommitted data of another transaction B, which is called dirty read
and non-repeatable read : Transaction A is interfered by transaction B! Within the scope of transaction A, two identical queries read the same record, but returned different results, that is, non-repeatable read
phantom reading : transaction A queries the result set within a range, and another concurrent transaction B goes to this Data is inserted/deleted in the range and submitted. Then transaction A queried again, and as a result, different results were found, which is a phantom read.

2. Transaction isolation level

In the case of concurrency, under the transaction isolation level of read uncommitted, there is no lock, and there will be problems of dirty read, phantom read and non-repeatable read

3. InnoDB seven kinds of lock introduction

3.1 Shared/exclusive locks

The InnoDB storage engine implements two standard row-level locks: shared lock-Share (referred to as S lock), exclusive lock (referred to as X lock)

Shared lock: When a transaction wants to read a record, it needs to acquire the shared lock of the record first.

Exclusive lock: When a transaction wants to modify a record, it needs to acquire the exclusive lock of the record first.

The meaning of shared lock

There are several transactions that want to read a record, they need to obtain the shared lock of the record first, in order to prevent the record from being modified by other transactions.

The meaning of exclusive lock

When a transaction wants to modify a record, it needs to obtain an exclusive lock on the record first. At this time, other transactions cannot read the data until the exclusive lock is released.

3.2 Intention lock

Intention lock explanation : table-level locks that do not conflict with row-level locks. At some point in the future, when a transaction may need to add a shared lock or an exclusive lock, declare an intention in advance. Is a table-level lock.

Why do you need an intent lock?

Suppose a transaction A acquires an exclusive lock on a row of data in the table
At this time, transaction B wants to read the data of the entire table, and needs to add a shared lock to the entire table, so it is necessary to ensure that there is no exclusive lock in the table
here comes the problem
- Transaction B wants to determine whether there is an exclusive lock in the table. Does it need to traverse the entire table?
- In order to solve this problem, there is an intention lock

Actual running process

When a transaction A wants to read/modify the data in the table, it needs to add a full table-level intention shared lock/intent exclusive lock
At this time, if other transactions want to modify the data in the whole table, they will find that there is an intention lock at the whole table level in the table, so that there is no need to avoid the need to find locks in the whole table

3.3 Record lock

A record lock is the smallest granularity lock, only locking one row.
The record lock is added to the index. If there is no index in a table, InnoDB will implicitly create an index and use the index to add a record lock.
record lock keywordlock_mode X locks rec but not gap

3.4 Gap Lock (Gap Lock)

A gap lock is a lock added between two indexes, or a gap added before the first index and after the last index, which locks an interval.
lock_mode X locks gap before rec
In order to solve the problem of phantom reading,
the left and right sides of the gap lock are open intervals

When an SQL statement queries range data, a gap lock is added to the query range interval.
At this time, other transactions cannot insert new data in the range with the gap lock, which avoids phantom reading.

Gap lock only occurs under RR isolation level

PS: Under the isolation level of RR (repeatable read), ordinary queries are snapshot reads, and phantom reads will not occur. Phantom reading is only possible if "current reading" (ie: for update) is used

3.5 Next-Key Lock

Adjacent key lock: lock the index itself and the gap before the index, open the left and right close intervals

The locking scenario of the key lock: When SQL uses the condition of the non-unique index for data retrieval, the key lock will be added to the matched row

Data in the following table

id	name	sex	age
1	kk	male	10
2	lily	male	20
3	LiNa	male	30
4	QQ	male	40
5	HH	male	60
6	ZZ	male	80
7	NN	male	100

Add an ordinary non-empty unique index to the age column of the table.
Then the possible interval of the key lock is

(minus infinity, 10] (10, 20] (20, 30] (30, 40] (40, 60] (60, 80] (80, 100] (100, plus infinity)

The specific production scene of the key lock:

If it is an equivalent query and the record exists, that is, begin; select * from xxx where age = 30 for update;

At this time, only the line record age=30 will be locked

Equivalent query and the record does not exist, that is, begin; select * from xxx where age = 45 for update;

At this time, the gap between [40, 60] will be locked. If 40 <= age <= 60, the insertion will fail

Range query select * from where age >= 25 and age <=35

First query the record with age = 25 to determine whether it exists, and there is no key lock (20, 30]

Same as above age = 35 does not exist, lock (30, 40]

Total acceleration range Next-Key Lock (20, 40]

Summary of locking rules

Unique index equivalent query

Query record exists, record lock Record Lock

Does not exist, gap lock Gap Lock

Unique index range query

gap lock or record lock

Non-unique index equivalent query

Record the existence of Next-key Lock Pro key lock and gap lock Gap Lock

Record does not exist gap lock Gap Lock

Non-unique index range query

Next-Key Lock Pro key lock

3.6 Insert intent lock

A gap lock that is set before inserting a row of records.
solved problem:

When multiple transactions perform insert operations within the same index range, if the inserted data does not conflict, they will not block each other.
Assuming that the data range [7, 100] is multiple, it will not block when inserting different data in the range interval

3.7 Self-increasing lock

Special table-level locks for AUTO_INCREMENT

If a new piece of data is added to the table, it will hold a self-increasing lock
At this time, other transactions inserting data into the table must wait for the self-increasing lock to be released in order to ensure continuous primary key values

MySql lock knowledge record accumulation (1)