Today, we will introduce three other types of InnoDB: shared/exclusive locks , intent locks , and insert intent locks .
One, shared/exclusive locks ( Shared and Exclusive Locks )
Why is InnoDB concurrency so high? "The article introduces common shared/exclusive locks, and of course standard row-level locking is also implemented in InnoDB, shared/exclusive locks :
(1) The transaction obtains the shared S lock of a row of records before it can read this row;
(2) The transaction obtains the exclusive X lock of a row of records before it can modify or delete this row;
Its compatible mutex table is as follows:
S X
S compatible mutex
X Mutual exclusion Mutual exclusion
which is:
(1) Multiple transactions can obtain an S lock, and reading and reading can be performed in parallel ;
(2) And only one transaction can get the X lock, and write/write must be mutually exclusive ;
The potential problem of shared/exclusive locks is that they cannot be fully parallelized. The solution is to have multiple versions of data . The specific idea is in " Why is InnoDB Concurrency So High?" ” has been introduced, and will not be further expanded here.
2. Intention Locks
InnoDB supports multiple granularity locking, which allows row-level locks and table-level locks to coexist. In practical applications, InnoDB uses intent locks.
Intention lock means that, at some point in the future, the transaction may need to add a shared/exclusive lock, and an intention is declared in advance.
Intention locks have the following characteristics:
(1) First, the intent lock is a table-level locking;
(2) Intentional locks are divided into:
-
Intention shared lock (IS), which indicates that the transaction intends to add a shared S lock to some rows in the table
-
Intention exclusive lock (IX), which indicates that the transaction intends to add an exclusive X lock to some rows in the table
for example:
select ... lock in share mode , to set IS lock ;
select ... for update , to set the IX lock ;
(3) The intent locking protocol is not complicated:
-
To obtain an S lock on some rows, a transaction must first obtain an IS lock on the table
-
For a transaction to obtain X locks on some rows, it must first obtain IX locks on the table
(4) Since the intention lock only expresses the intention, it is actually a relatively weak lock. The intention locks are not mutually exclusive, but can be parallelized. The compatible mutual exclusion table is as follows:
IS IX
IS Compatible Compatible
IX compatible compatible
(5) Well, since intention locks are compatible with each other, what is the significance? It will be mutually exclusive with shared locks/exclusive locks, and its compatible mutex table is as follows:
S X
IS Compatible Mutual Exclusion
IX Mutual exclusion Mutual exclusion
Voiceover: Exclusive locks are strong locks and are not compatible with other types of locks. This is also well understood. When modifying and deleting a row, a strong lock must be obtained to prohibit other concurrency on this row to ensure data consistency.
Three, Insert Intention Locks ( Insert Intention Locks )
For the modification and deletion of existing data rows , the mutual exclusion lock X lock must be strengthened . For data insertion , is it necessary to strengthen such a strong lock to implement mutual exclusion? Insert the intent lock, conceived and born.
Insert intention lock is a type of Gap Locks (so, it is also implemented on the index), which is specifically for insert operations.
Voice-over: It's a bit embarrassing. The gap lock will be introduced in the next article. For the time being, it is understood that it is a lock implemented on the index to lock a certain range of the index.
How it works is:
When multiple transactions insert records in the same index and the same range, if the inserted positions do not conflict, they will not block each other .
Voice-over: The official website says that
Insert Intention Lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap.
In this way, the previous example of digging a pit can be answered.
Under MySQL, InnoDB, RR:
t(id unique PK, name);
The data table has data:
10, shenjian
20, zhangsan
30, lysis
Transaction A is executed first, inserting a row into records 10 and 20 , but not yet committed:
insert into t values(11, xxx);
After transaction B is executed, a row is also inserted into the records 10 and 20 :
insert into t values(12, ooo);
(1) What lock will be used?
(2) Will transaction B be blocked?
Answer : Although the transaction isolation level is RR, although it is the same index and the same interval, the inserted records do not conflict, so here:
-
Insert intent lock is used
-
does not block transaction B
Summary of ideas
(1) InnoDB uses shared locks , which can improve read and read concurrency ;
(2) In order to ensure strong data consistency , InnoDB uses strong mutual exclusion locks to ensure the seriality of modification and deletion of records in the same row;
(3) InnoDB uses insert intent locks , which can improve insert concurrency ;
end
Assuming that it is not insert concurrency, but read and write concurrency, what will be the result?
MySQL, InnoDB, default isolation level (RR).
t(id unique PK, name);
The data table has data:
10, shenjian
20, zhangsan
30, lysis
Transaction A is executed first, and some records are queried , but not yet committed:
select * from t where id>10;
After transaction B is executed, a row is inserted into the records 10 and 20 :
insert into t values(11, xxx);
here:
(1) What lock will be used?
(2) Will transaction B be blocked?
Please see "InnoDB, why does select block insert? 》