The fine-grained row locking of MySQL's InnoDB is one of its most attractive features.
However, as described in InnoDB, 5 Best Practices , queries that do not hit an index will also degenerate into table locks.
InnoDB's fine-grained locking is implemented on index records.
First, the index of InnoDB
There are two types of indexes in InnoDB, Clustered Index and Secondary Index.
Every table in InnoDB will have a clustered index :
(1) If the table defines PK, then PK is the clustered index;
(2) If the table does not define PK, the first non-empty unique column is a clustered index;
(3) Otherwise, InnoDB will create a hidden row-id as a clustered index;
For the convenience of description, the following text will be described with PK.
The structure of the index is a B+ tree . The details of the B+ tree are not expanded here, but a few conclusions are made:
(1) In the index structure, non-leaf nodes store keys, and leaf nodes store values;
(2) Clustered index , leaf nodes store row records (row) ;
Voiceover: So, InnoDB indexes and records are stored together, while MyISAM indexes and records are stored separately.
(3) Ordinary index , the leaf node stores the value of PK ;
Out-of-picture sound:
Therefore, the normal index of InnoDB will actually be scanned twice:
In the first pass, the PK is found by the ordinary index;
The second time, find the row record by PK;
Index structure, the index structure of InnoDB/MyISAM, if you are interested, I will write a detailed article in the future.
As an example, suppose there is an InnoDB table:
t(id PK, name KEY, sex, flag);
There are four records in the table:
1, shenjian, m, A
3, zhangsan, m, A
5, lisi, m, A
9, wangwu, f, B
to see:
(1) The first picture, the clustered index of id PK, the leaves store all row records;
(2) The second picture, the ordinary index on the name, the leaf stores the value of PK;
for:
select * from t where name=’shenjian’;
(1) PK=1 will be queried on the common index of name first;
(2) Then query the row records of (1, shenjian, m, A) in the clustered index shirt;
The following briefly introduces the remaining three of the seven types of locks in InnoDB:
-
Record Locks
-
Gap Locks
-
Next-Key Locks
For the convenience of description, in the following text, the default transaction isolation level is Repeated Read (RR) unless otherwise specified.
2. Record Locks
A record lock , which blocks index records , for example:
select * from t where id=1 for update;
It will put a lock on the index record with id=1 to prevent other transactions from inserting, updating, and deleting the row with id=1.
It should be noted:
select * from t where id=1;
It is a snapshot read (SnapShot Read), which does not lock, specifically in " Why is InnoDB high concurrency and fast reading? " is described in detail.
3. Gap Locks
Gap locks , which block gaps in index records , or the range before the first index record, or the range after the last index record.
Still the above example, InnoDB, RR:
t(id PK, name KEY, sex, flag);
There are four records in the table:
1, shenjian, m, A
3, zhangsan, m, A
5, lisi, m, A
9, wangwu, f, B
this SQL statement
select * from t
where id between 8 and 15
for update;
The interval will be blocked to prevent the insertion of records with id=10 by other transactions.
Out-of-picture sound:
Why are records with id=10 blocked from inserting?
If the insertion is successful, the first transaction executes the same SQL statement, and it will find that there is one more record in the result set, that is, phantom data.
The main purpose of gap locks is to prevent other transactions from inserting data in the gap , resulting in "non-repeatable reads".
If the isolation level of the transaction is downgraded to Read Committed (RC), the gap lock will be automatically invalidated.
4. Next-Key Locks
A key-proximity lock is a combination of a record lock and a gap lock . Its blocking range includes both index records and index ranges.
More specifically, a near-key lock will block the index record itself, as well as the interval before the index record.
If a session holds a shared/exclusive lock on index record R, other sessions cannot immediately insert new index records in the interval before R.
Voice-over: The original
If one session has a shared or exclusive lock on record R in an index, another session cannot insert a new index record in the gap immediately before R in the index order.
Still the above example, InnoDB, RR:
t(id PK, name KEY, sex, flag);
There are four records in the table:
1, shenjian, m, A
3, zhangsan, m, A
5, lisi, m, A
9, wangwu, f, B
Potential pro-key locks on the PK are:
(-infinity, 1]
(1, 3]
(3, 5]
(5, 9]
(9, +infinity]
The main purpose of the key lock is to avoid Phantom Read. If the isolation level of the transaction is downgraded to RC, the key lock will also fail.
Voice-over: Regarding the isolation level of transactions and phantom reading, the previous article has not explained it. If you are interested, it will be described in detail later.
Today's content mainly introduces the index of InnoDB and the concepts of three locks. Scenarios and examples are also the simplest scenarios and simplest examples.
InnoDB locks are related to index types and transaction isolation levels. More complex and interesting cases will be introduced later.
V. Summary
(1) InnoDB indexes are stored with row records , which is different from MyISAM;
(2) The clustered index of InnoDB stores row records, and the ordinary index stores PK, so the ordinary index needs to be queried twice ;
(3) The record lock locks the index record;
(4) The gap lock locks the interval to prevent the interval from being inserted by other transactions;
(5) The key lock locks the index record + interval to prevent phantom reading;