MySQL Advanced Road (14) - What is the lock in InnoDB? One to understand it!
Contents of this article
I. Overview
In the previous article, the MVCC mechanism was introduced in detail. It solves the problem of how to read when other transactions are updated, and what we will introduce today is to solve the problem of how other things are updated when they are updated. In fact, the locking mechanism is not only in MySQL, you can see it in many computer languages, such as Java, and middleware, such as redis also has a locking mechanism. All in all, without locking, our computer world would be chaotic, programs wouldn't cooperate, and code would be extremely complex.
2. How locks work in MySQL
In MySQL, locks control access to resources (such as tables, rows, or internal data structures). For example, there cannot be more than 1 transaction to update the same row of data or the same table at the same time, or a transaction is not allowed to update the table. When another thing goes to insert or delete some data in the table.
Locks in InnoDB use a lightweight structure, and transactions are typically held for a short period of time (measured in milliseconds or microseconds). This should also be well understood. Two people and things, A and B, update the same row of data at the same time. A first adds a lock, and then starts to update the data. At this time, B also wants to update the data, then he will see if the lock is held. Yes, if there is, wait and see if anyone holds it later. In the above process, each thing will generate a lock data interface, which records the trx_id and waiting state. When things update a row of data, the lock will be added to that row of data. If other things are found to have been preempted Just set the wait until state of your lock to true, wait first, and try again later. like below
The lock in the above example is a mutual exclusion lock, that is, only one person can lock the data at most. An exclusive lock in the database
3. What locks are there in MySQL?
There are the following types of locks in InnoDB:
- shared lock/exclusive lock
- intent lock
- record lock
- gap lock
- Next-Key锁
- Intent Insertion Lock
- AUTO-INC lock
- predicate lock
Let's take a look at what they are. Here we only introduce the ones that are most closely related to us. For some rare ones, you can check the relevant information by yourself.
shared lock/exclusive lock
The English name is Shared and Exclusive Locks, so it is also referred to as S lock and X lock . The function of this lock is just as the name suggests. The following is an example: After thread A locks the data with S lock, thread B can also add S lock to this data, but it cannot add X lock to this data, because X lock is mutually exclusive, and only one thing is allowed to be added at the same time. Lock. I believe this is not difficult to understand, so what about the application scenario? It should not be difficult to know that the S lock allows multiple transactions to share a row of data. It must be when all the transactions with the S lock are reading , so that confusion will not occur, so what about the X lock? In fact, it is very simple and definitely when updating or deleting , because this kind of operation absolutely does not allow multiple transactions to be performed on the same data at the same time!
Therefore, it is not difficult for us to know the functions of S lock and X lock:
S lock: Allows the transaction holding the lock to perform read operations
X lock: Allows transactions with locks to update or delete operations
Note : Both S locks and X locks are loaded on the row, so they are also called row locks
intent lock
This lock only understands the meaning of "intent" after understanding its meaning. The lock in InnoDB supports multi-granularity. The row lock is mentioned above . This intention lock is actually a table lock , which is divided into intention shared lock ( IS lock ) and intention exclusive lock ( IX lock ), which are locked on the table. How is this intent lock used? Recall how we found a piece of data, did we find the corresponding table first, and then find the corresponding row, right? This locking process is actually the same. Before obtaining the lock on the row, you need to obtain the lock on the table. When adding the S lock to the next row, you need to first obtain the IS lock on the table. Similarly, when adding an X lock to a row When you need to obtain the IX lock on the table first. (Note: Unlike S/X locks, multiple transactions are allowed to add IS locks and IX locks to the table, but only one transaction can acquire the IX lock on the table at a time ).
The following are the SQL statements for locking and acquiring locks:
# 可以通过下面的语句来获取指定表的意向排它锁（获取表的IX锁，只能有一个事物获取到）
LOCK TABLES ... WRITE
# 加上意向共享锁（加IS锁，同一个表可以加多个）
SELECT ... LOCK IN SHARE MODE
# 加上意向排他锁
SELECT ... FOR UPDATE（加IX锁，同一个表可以加多个）
# 查看事物的加锁状态（在Status列中的TRANSACTIONS部分可以查看）
SHOW ENGINE INNODB STATUS
The following is the compatibility relationship between these locks:
| X | IX | S | IS | |
|---|---|---|---|---|
| X | conflict | conflict | conflict | conflict |
| IX | conflict | Compatible | conflict | Compatible |
| S | conflict | conflict | Compatible | Compatible |
| IS | conflict | Compatible | Compatible | Compatible |
At this point, it is not difficult for us to figure out the role of intentional locks:
In addition to this full operation, the intention lock will not prevent anything. It is just the table name intention, indicating that something is or may operate on a row of data later, which is also the origin of the name "intent".LOCK TABLES ... WRITE
record lock
Record locks, as the name suggests, are used on indexed records. When a record of an index is locked, it can prevent other things from inserting, updating or deleting this record. The row-level lock mentioned above is essentially a record lock
If you do not create an index, then InnoDB will create a hidden local clustered index
gap lock
Gap lock, as the name suggests, is used to lock the gap, what kind of gap is that? In fact, it is the gap of the index. You may have questions, under what circumstances do you need to lock the gap of the index? Let me give an example: now transaction A is executing such an SQL statement: SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20, after transaction A finishes executing this SQL, a transaction B inserts data c1 = 11, and then transaction A executes this statement again before committing , At this time, transaction A finds that the data obtained from the same range twice before and after are actually different? This situation is what I said in the previous article 幻读, like a hallucination!
For this WHERE condition with a range condition, in order to prevent phantom reads, we need to add a gap lock to the gap within this range. The SQL is written like this: SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE, After doing this, it will prevent other things from going to 10 The operation of inserting data in the range of 15
A gap may span single or multiple index values, and may even be empty. A statement that uses a unique index to search for unique rows does not require gap locks.
SELECT * FROM child WHERE id = 100;
If idthe column is not indexed or has a non-unique index, the statement locks the preceding gap.
It is worth noting that for the same gap, multiple transactions can be allowed to add gap locks to it.
After understanding the above content, it is not difficult for us to figure out the role of the gap lock:
A gap Gap locks can coexist. A gap lock taken by one transaction does not prevent another transaction from taking a gap lock on the same gap. There is no difference between a shared gap lock and an exclusive gap lock. They do not conflict with each other and perform the same function.
Next-Key锁
From the name, it is really not easy to understand. Let me first talk about what this lock looks like. The so-called Next-Key lock is actually a combination of gap lock + record lock . Its function is to prevent the occurrence of phantom reading. Speaking of gap locks, it can only guarantee that the amount of data in the two range queries before and after one thing is the same, but it cannot prevent the data from being modified. Therefore, the gap lock alone may cause non-repeatable reads. In order to prevent this from happening , and watch the record lock to use in conjunction.
InnoDB, the default is the REPEATABLE READ isolation level. When searching or scanning the index, it will add gap locks and record locks to the gaps and records encountered, that is, Next-Key locks, one after the other, which can prevent other Things insert new records in front. This may be the origin of the name of the Next-Key lock, as its locking behavior - one after the other
In summary, the role of Next-Key locks can be seen:
InnoDB uses Next-Key locks at the REPEATABLE READ level to prevent phantom reads from occurring
other locks
For intentional insertion locks , AUTO-INC locks and predicate locks , this article will not elaborate on them because they are relatively biased. If you are interested, you can check the relevant information by yourself. After understanding the locks explained above, I believe that the remaining locks are certainly not difficult to understand
4. Summary
Today, I introduced the locks in InnoDB, as well as the common types. Their granularity and function are different, and they are born to solve different problems. Therefore, it is very important to understand what problems they are used to solve!
The above is the whole content of this article. If there is any problem, please point it out and make progress together