Table of contents
2. Global locks, table-level locks, page-level locks, row-level locks
3. Optimistic lock and pessimistic lock
Fourth, shared locks and exclusive locks
5. Intention shared lock and intention exclusive lock
6. Gap lock, key lock, record lock
Classification and use of locks
1. Classification of locks
1. MySQL locks can be classified by mode into:
- optimistic lock
- Pessimistic lock.
2. According to the granularity, it can be divided into:
- global lock
- table lock
- page lock
- Row-level locks.
3. According to attributes, it can be divided into:
- shared lock
- Exclusive lock.
4. According to the state, it is divided into:
- intent shared lock
- Intent-exclusive lock.
5. According to the algorithm, it is divided into:
- gap lock
- Pro key lock
- Record lock.
2. Global locks, table-level locks, page-level locks, row-level locks
1. Global lock
(1) concept
The global lock is to lock the entire database instance.
(2) Application scenarios
Full database logical backup (mysqldump)
(3) Implementation method
MySQL provides a way to add a global read lock, the command is Flush tables with read lock (FTWRL).
When you need to make the entire library in a read-only state, you can use this command, and then the following statements of other threads will be blocked: data update statement (addition, deletion and modification of data), data definition statement (including table creation, table structure modification, etc. ) and a commit statement for an update transaction.
risk point:
- If it is backed up on the main library, no updates can be performed during the backup period, and the business can basically stop.
- If it is backed up on the slave library, the slave library cannot execute the binlog synchronized from the master library during the backup, which will cause master-slave delay.
Solution:
mysqldump uses the parameter --single-transaction to start a transaction to ensure a consistent view. Due to the support of MVCC, the data can be updated normally during this process.
2. Table-level locks
(1) concept
The entire table currently being operated is locked, and the most commonly used MyISAM and InnoDB both support table-level locking.
There are two types of table-level locks in MySQL: one is a table lock , and the other is a metadata lock ( meta data lock, MDL).
(2) Implementation method
表锁：lock tables … read/write；
For example, lock tables t1 read, t2 write; command, the statements of other threads writing t1, reading and writing t2 will be blocked. At the same time, thread A can only perform the operations of reading t1 and reading and writing t2 before executing unlock tables. Even writing to t1 is not allowed, and naturally you cannot access other tables before unlocking tables.
Metadata lock: MDL does not need to be used explicitly, and it will be added automatically when accessing a table. MDL was introduced in MySQL 5.5. When adding, deleting, modifying and querying a table, MDL read lock is added; when When you want to change the structure of the table, add MDL write lock.
(3) Risk point:
Adding fields to a table, or modifying fields, or adding indexes requires scanning the data of the entire table. When operating large tables, you must be very careful to avoid affecting online services. In fact, even if it is a small watch, there will be problems if it is not operated carefully.
(4) Solutions
First of all, we need to solve the long transaction. If the transaction is not committed, it will always occupy the MDL lock. In the innodb_trx table of MySQL's information_schema library, you can check the currently executing transactions. If the table you want to modify by DDL happens to have a long transaction in execution, consider suspending the DDL first, or kill the long transaction. This is why ddl changes need to be made during off-peak periods.
3. Page-level lock
Page-level lock is a kind of lock in MySQL whose locking granularity is between row-level lock and table-level lock. Table-level locks are fast, but have more conflicts, and row-level locks have fewer conflicts, but are slower. Therefore, a compromised page-level lock is adopted to lock a group of adjacent records at a time. The BDB engine supports page-level locking.
4. Row-level locks
(1) concept
Row-level locks are the locks with the lowest granularity, the lowest probability of lock conflicts, and the highest concurrency. But locking is slow, expensive, and prone to deadlocks.
In MySQL, only InnoDB supports row-level locks . Row-level locks are divided into shared locks and exclusive locks .
(2) Implementation method
In MySQL, row-level locks do not directly lock records, but lock indexes. Indexes are divided into primary key indexes and non-primary key indexes. If a SQL statement operates a primary key index, MySQL will lock the primary key index; if a statement operates a non-primary key index, MySQL will first lock the non-primary key index, and then lock The associated primary key index. During UPDATE and DELETE operations, MySQL not only locks all index records scanned by the WHERE condition, but also locks adjacent key values, which is the so-called next-key locking.
3. Optimistic lock and pessimistic lock
1. Optimistic locking
(1) concept
Optimistic locking is relative to pessimistic locking. Optimistic locking assumes that the data will not cause conflicts under normal circumstances , so when the data is submitted for update, it will formally detect whether the data conflicts or not . If a conflict is found, it will return Give the user wrong information and let the user decide what to do.
(2) Application scenarios
It is suitable for more reads and fewer writes , because if there are a large number of write operations, the possibility of write conflicts will increase, and the business layer needs to be retried continuously, which will greatly reduce system performance.
2. Pessimistic lock
(1) concept
Pessimistic lock, as its name suggests, has strong exclusive and exclusive characteristics. Every time you go to get data, you think that others will modify it, and the data is modified by the outside world (including other current transactions of the system, as well as transaction processing from external systems) Be conservative, therefore, keep the data locked during the entire data processing process.
(2) Application scenarios
It is suitable for scenarios with low concurrency, frequent write operations, and high data consistency.
(3) Implementation method
To use pessimistic locks in MySQL, MySQL's autocommit must be turned off, set autocommit=0. Shared locks and exclusive locks are different implementations of pessimistic locks , both of which belong to the category of pessimistic locks.
Fourth, shared locks and exclusive locks
1. Shared lock
(1) concept
Shared locks, also known as read locks, or S locks for short, when transaction A adds read locks to the data, other transactions can only add read locks to the data, and cannot do any modification operations, that is, cannot add write locks. Only after the read lock on transaction A is released, other transactions can add write locks to it.
(2) Application scenarios
Shared locks mainly appear to support concurrent reading of data . When reading data, other transactions are not allowed to modify the current data, thereby avoiding the problem of "non-rereadable" .
It is suitable for writing operations when there is a relationship between two tables. Taking the example of the official mysql document, one table is a child table and the other is a parent table. Assuming that a column child_id of the child table is mapped to the c_child_id column of the parent table, then from the business From a perspective, it is risky for me to directly insert a record of child_id=100 into the child table at this time, because the record of c_child_id=100 may be deleted in the parent table when I just inserted, so there is a risk of inconsistency in business data. The correct way is to execute select * from parent where c_child_id=100 lock in share mode when inserting, lock this record in the parent table, and then execute insert into child(child_id)values (100) so that this problem will not exist .
(3) Implementation method
select …lock in share mode
2. Exclusive lock
(1) concept
Exclusive locks, also known as write locks, or X locks for short, when a transaction adds a write lock to the data, other transactions can neither add reads or writes to the data, nor can they add a write lock to the data. Write locks are different from other locks are mutually exclusive. Only after the current data write lock is released, other transactions can add write locks or read locks to it.
By default, the MySQL InnoDB engine will automatically add an exclusive lock to the data involved in update, delete, and insert, and the select statement will not add any lock type by default.
(2) Application scenarios
The write lock is mainly to solve the problem of not allowing other transactions to modify and read the current data when modifying the data , so as to effectively avoid the "dirty read" problem .
(3) Implementation method
select …for update
5. Intention shared lock and intention exclusive lock
1. Concept
Intention locks are table locks. In order to coordinate the relationship between row locks and table locks , multi-granularity (table locks and row locks) coexistence is supported.
2. Function
When there is a row lock in transaction A, MySQL will automatically add an intent lock to the table. If transaction B wants to apply for a write lock on the entire table, it does not need to traverse each row to determine whether there is a row lock, but directly judge whether there is an intent lock. Enhance performance.
3. Compatibility and mutual exclusion of intent locks
| Intent shared lock (IS) | Intent exclusive lock (IX) | |
|---|---|---|
| shared lock(s) | compatible | mutually exclusive |
| exclusive lock (X) | mutually exclusive | mutually exclusive |
6. Gap lock, key lock, record lock
concept
Record locks, gap locks, and adjacent key locks are all exclusive locks , and the use of record locks is consistent with the introduction of exclusive locks.
1. Record lock
A record lock is a blocked record, and a record lock is also called a row lock, for example:
select *from goods where **`id`=**1 for update;
It will add a record lock on the record with id=1 to prevent other transactions from inserting, updating, and deleting the row with id=1.
2. Gap lock
Gap locks are based on non-unique indexes , which lock a range of index records. What is locked by gap lock is an interval, not just every piece of data in this interval.
select* from goods where id between 1 and 10 for update;
That is, all record rows in the interval (1, 10) will be locked, and the insertion of all data rows with ids of 2, 3, 4, 5, 6, 7, 8, and 9 will be blocked, but both 1 and 10 record line will not be locked.
3. Pro key lock
Proximity key lock is a combination of record lock and gap lock. Its blocking range includes both index records and index intervals, which is a left-open and right-close interval . The main purpose of the key lock is also to avoid phantom reads (Phantom Read). If the isolation level of the transaction is downgraded to RC , the key lock will also fail.
There will be a temporary key lock on the non-unique index column on each data row. When a transaction holds the temporary key lock of the data row, it will lock a section of data in the left-open and right-close interval. It should be emphasized that row-level locks in InnoDB are implemented based on indexes, temporary key locks are only related to non-unique index columns, and temporary key locks do not exist on unique index columns (including primary key columns).
Shoulders of Giants: Detailed Explanation of the Most Complete MySQL Locks in History Develop Paper