(I. Overview
We call those resources that may be operated by multiple threads at the same time as critical resources. The purpose of locking is to allow only one thread to access these critical resources at the same time. This is the concept of locks that was put forward when talking about synchronized locks at that time.
As a resource shared by users, how to ensure the consistency of data concurrent access is also a problem that all databases must solve. How to lock is an important factor in the performance of concurrent database access.
(B) About the database lock
From the locking form, it is divided into optimistic lock and pessimistic lock
From the type of database operation, it is divided into read locks (shared locks) and write locks (exclusive locks)
Read lock : multiple read operations can be performed at the same time without affecting each other.
Write lock : before the current write operation is completed, other read locks and write locks will be excluded
From the granularity of data operations can be divided into table locks and row locks
2.1 Table lock
As the name implies, a table lock is to lock the entire table. This kind of operation has low overhead, fast locking, and no deadlock, but the lock granularity is large and the concurrency is low. The MyISAM engine will automatically add table locks to the data when operating the data.
You can manually increase the table lock through the following parameters:
lock table 表名 read(write)
- 1
View the locks added on the table:
show open tables;
- 1
Remove lock:
unlock tables;
After the read lock is added, the write will be restricted; after the write lock is added, the read and write will be restricted;
2.2 Row lock
Row lock is to lock a row of data. This method is expensive, slow to lock, and deadlock occurs. However, the granularity of the lock is small and the concurrency is the highest. InnoDB supports row locks, while InnoDB also supports transactions .
To introduce row locks through a simple example, we open two sessions (in Navicat is to open two query windows) to operate the database, in which the data is modified in the first query, but not submitted:
begin;
update test_innodb set name='javayz2' where id=1;
At this time, use another query window to modify the same row of data:
update test_innodb set name='javayz3' where id=1;
At this time, this line of update statement will be blocked forever, now submit the modified data in the first query:
commit
You will find that the modification in the second query also takes effect immediately:
viewing the results, blocking for 30 seconds
Note: InnoDB's row lock is added to the index. If the index fails or the non-indexed field is modified, the row lock will be upgraded to a table lock.
(Three) Mysql transaction isolation level
Before talking about the transaction isolation level, you need to make sure to know the following concepts:
ACID properties of transactions: atomicity, consistency, isolation, and durability .
Problems that may be caused by concurrency: missing updates, dirty reads, non-repeatable reads, and phantom reads .
Update loss : that is, multiple transactions update a row of data at the same time, causing the last update to cover the update of the previous transaction.
Dirty read : Transaction A reads the modified but uncommitted data of transaction B.
Non-repeatable read: That is, transaction A reads some data and then reads the data, and finds that the data has changed . Because transaction A reads the data submitted by other transactions, it does not meet the isolation.
Phantom reading : that is, after transaction A reads some data and reads it under the same conditions, it finds that there is more new data. It is also because transaction A reads the new data of other transactions, which does not meet the isolation.
After understanding the above concepts, you can know the transaction isolation level of Mysql. There are four transaction isolation levels, which are shown in the form of a table below:
| Isolation level | Dirty read | Non-repeatable | Phantom reading |
|---|---|---|---|
| Read uncommitted (read-uncommitted) | √ | √ | √ |
| Read has been submitted (read-committed) | × | √ | √ |
| Repeatable-read | × | × | √ |
| Serializable | × | × | × |
The stricter the isolation level, the smaller the problems caused by concurrency, but the lower the degree of concurrency.
Mysql's default transaction isolation level is repeatable read . Can be viewed by the following statement
show VARIABLES like 'tx_isolation'
Modify the transaction isolation level through the following statement:
set tx_isolation='READ-COMMITTED'
//READ-UNCOMMITTED、READ-COMMITTED、REPEATABLE-READ、SERIALIZABLE
(4) MVCC mechanism
When the transaction isolation level is set to repeatable read, after transaction A executes select, if transaction B modifies the data, transaction A then select is still the last data , but if insert, update, and delete are used, the data used will be Is the modified data of transaction B,
For example, the first query of transaction A is 23, transaction B adds 1 to age, and the second query of transaction A is still 23; if transaction A adds 1 to age, the query is 25.
The repeatable isolation level uses the MVCC (multi-version concurrency control) mechanism. Its implementation mechanism is more complicated. I will post a special article to talk about it later. The purpose he achieved is that the select operation reads the historical snapshot version, and insert, update, and delete update the latest version .
(5) How to solve the problem of phantom reading in the case of repeatable reading
Mysql's default transaction isolation level is repeatable reading, but it does not solve the problem of phantom reading. If it is changed to be serializable, the concurrency is too low. Therefore, whether the phantom reading problem can be solved in the case of repeatable reading is also in the interview. I met more often.
The solution is to use a gap lock . When the update statement is executed in one of the transactions, add a range, such as:
update test_innodb set name='javayz3' where id>1 and id<10
Data with an id between 1 and 10 cannot be inserted or modified in other transactions, and naturally there will be no phantom reading.
(6) About deadlock
In the project, you will occasionally encounter a deadlock. The deadlock is actually very simple. SessionA is waiting for the completion of sessionB, and sessionB is waiting for the completion of sessionA, forming an endless loop. For example, the following update statement:
A：begin;
update test_innodb set name='aa' where id=1; //锁住id为1的行
B：begin;
update test_innodb set name='bb' where id=2; //锁住id为2的行
A：update test_innodb set name='aa' where id=2;
B：update test_innodb set name='bb' where id=1;
Eventually A is blocked by B, and B is blocked by A, which leads to a deadlock.
A deadlock handling mechanism has been added to Mysql. For deadlocks, it will be unlocked by rollback, but sometimes it cannot be unlocked when encountering complex deadlocks.
(7) Summary
The entire article first talks about Mysql locks, Myisam uses table locks, and InnoDB uses row locks. Then introduced the basic principles of transactions, thereby bringing out the transaction isolation level of Mysql. The MVCC mechanism is briefly introduced, and then the gap lock and deadlock are explained. Mastering these will give you ideas for solving Mysql problems at work or during interviews. Okay, that's all the content of this issue, see you next time!