[MySQL Series] - MYSQL lock mechanism

[MySQL Series] - MYSQL lock mechanism

Simply put, the database locking mechanism is a rule designed by the database to ensure the consistency of data and to make various shared resources orderly when accessed concurrently.

Due to the characteristics of its own architecture, the MySQL database has multiple data storage engines. The locking mechanisms of each storage engine are optimized and designed for the specific scenarios they face, so the locking mechanisms of each storage engine are also quite different.

1. Table-level lock

Table-level locking locks the entire table for each operation. The locking granularity is large, the probability of lock conflict is the highest, and the concurrency is the lowest. Applied in storage engines such as MyISAM, InnDB, and BDB, table-level locks are generally divided into 1). Table locks 2). Metadata locks 3). Intention locks.

Read lock on table

lock tables 表名.. read; -- 是指可以对多张表加锁

table exclusive lock

lock tables 表名... write; -- 可以对多张表加独占锁

release lock

unlock tables; -- 释放锁，客户端短裤连接

2. Row-level locks

Row-level locking locks the corresponding row data for each operation. The locking granularity is the smallest, the probability of lock conflicts is the lowest, and the concurrency is the highest. Applied in InnoDB storage engine. InnoDB data is organized based on indexes, and row locks are implemented by locking index entries on the index, rather than locking records.

For row-level locks, they are mainly divided into the following three categories:

1. Row lock (Record Lock) : Locks a single row record to prevent other transactions from updating and deleting the row. Supported under RC and RR isolation levels
2. Gap Lock : Locks the index record gap (excluding the record) to ensure that the index record gap remains unchanged and prevents other transactions from inserting in this gap and causing phantom reads. Supported under RR isolation level.
3. Next-Key Lock : A combination of row lock and gap lock, locking the data at the same time and locking the gap in front of the data. Supported under RR isolation level.

InnoDB implements the following two types of row locks:

1. Shared lock (S): allows one transaction to read a row and prevents other transactions from obtaining an exclusive lock on the same data set.
2. Exclusive lock (X): Allows the transaction that acquires the exclusive lock to update data, and prevents other transactions from acquiring shared locks and exclusive locks on the same data set.

SQL	row lock type	illustrate
INSERT…	exclusive lock	Automatically lock
UPDATE…	exclusive lock	Automatically lock
DELETE…	exclusive lock	Automatically lock
SELECT…	without any lock
SELECT… LOCK IN SHARE MODE	shared lock	Manual lock
SELECT…FOR UPDATE	exclusive lock	Manual lock

Gap Locks

Gap lock blocks the gap in the index record, or the range before the first index record, or the range after the last index record.

Conditions for generating gap locks (under RR transaction isolation level;)

1). Use ordinary index locking; 2). Use multi-column unique index; 3). Use unique index to lock multi-row records. For statements that use a unique index to search and lock a row of records. Only record locks will be generated, not gap locks.

Turn on gap lock settings

Check whether gap lock is enabled

show variables like 'innodb_locks_unsafe_for_binlog';

The default value of innodb_locks_unsafe_for_binlog is OFF, which enables gap locks. Because this parameter is in read-only mode, if you want to disable gap lock, you need to modify my.cnf and restart it to take effect.

[mysqld]
innodb_locks_unsafe_for_binlog = 1

in conclusion

1. For a locking statement that specifies a record to be queried, if the record does not exist, a record lock and a gap lock will be generated. If the record exists, a record lock will be generated, such as: WHERE Id=1 FOR UPDATE;
2. For query statements that search for a certain range, gaps will occur, such as: WHERE ID BETWEEN 5 AND 7 FOR UPDATE;
3. On ordinary index columns, no matter what kind of query, just locking will generate gap locks.

Next-key Locks

The temporary key lock is a combination of record lock and gap lock. Its blocking range includes both index records and index intervals.

The main purpose of the temporary key lock is also to avoid phantom read. If the isolation level of the transaction is downgraded to RC, the temporary key lock will also become invalid.

3. Page level lock

Locking is locking at the page granularity. The locked data resources are more than row locks, because there can be multiple row records in a page. When we use page locks, there will be a waste of data, but this waste is only one row of data on a page at most. The cost of page lock is between table lock and row lock, and deadlock will occur. The locking granularity is between table locks and row locks, and the concurrency is average.

4. Shared lock (S lock)

Shared Lock, also known as S lock and read lock. For row locks. When a transaction adds a read lock to the data, other transactions can only add read locks to the locked data and cannot add write locks (exclusive locks), so other transactions can only read but not write.

Locking method:

select * from Table where id=2 lock in share mode;

Release method:

commit 或 rollback;

5. Exclusive lock (X lock)

X lock, which is Exclusive Lock in English, is an exclusive lock. It can also be called Write Lock; X lock is exclusive. That is, a write lock will block other X locks and S locks. When a transaction needs to modify a record, it needs to obtain the X lock of the record first.

X lock lock format:

select ... for update;

6. Deadlock

Since Mysql has many types, deadlocks may occur in actual development.

6.1 Causes of deadlock

Deadlock refers to a phenomenon in which two or more processes wait for each other due to competition for resources during execution. Without external influence, they will not be able to proceed. At this time, the system is in a deadlock state or the system has a deadlock.

The key to deadlock is that the order in which two (or more) Sessions are locked is inconsistent.

The corresponding key to solving the deadlock problem is to lock different Sessions in order.

6.2 How to avoid deadlock

• Tables and rows are accessed in a fixed order. For example, between two transactions that update data, transaction A updates data in the order 1,2; transaction B updates data in the order: 2,1; this may cause a deadlock.
• Break down big things into small things. Large transactions are more prone to deadlock. If the business is running, split the large transaction into smaller ones.
• In the same transaction, try to lock all required resources at once to reduce the probability of deadlock.
• Lower the isolation level. If the business permits, it is also a better choice to lower the isolation level. For example, adjusting the isolation level from RR to RC can avoid many deadlocks caused by gap locks.
• Add reasonable indexes to the table. It can be seen that if the index is not used, a lock will be added to each row of the table, and the probability of deadlock will be greatly increased.

7. Summary

Since the InnoDB storage engine implements row-level locking, although the performance loss caused by the implementation of the locking mechanism may be higher than that of table locks, it is far superior to MyISAM's table locks in terms of overall concurrent processing capabilities. When the system concurrency is high, the overall performance of InnoDB will have obvious advantages compared with MyISAM.
However, InnoDB's row-level locks also have their fragile side. When we use them improperly, InnoDB's Not only can the overall performance not be higher than MyISAM, it may even be worse.

1. As much as possible, all data retrieval can be completed through the index to avoid index-free row locks from being upgraded to table locks.
2. Reasonably design indexes to minimize the scope of locks
3. Reduce index conditions and index ranges as much as possible to avoid gap locks
4. Try to control transaction size and reduce the amount and length of locked resources
5. Use low-level transaction isolation whenever possible (needs the business level to meet requirements)