[mysql]-[Lock]

Overview

Transaction isolation is achieved by the locks described in this chapter.

MySQL concurrent transactions access the same records

The situations in which concurrent transactions access the same records can be roughly divided into three types:

Read-read situation

Read-read situation, that is, concurrent transactions read the same record one after another. The read operation itself will not have any impact on the record and will not cause any problems, so this is allowed to happen.

write-write situation

Write-write situation, that is, concurrent transactions make changes to the same record one after another. In this case, the problem of dirty writes will occur (transaction one and transaction two each open a transaction, query a certain record, the result is 1, then transaction one changes the result to 2, transaction two changes the result to 3, and then transaction One commit, the other transaction is rolled back. At this time, the result of the database is 1, which is a dirty read). No isolation level allows this kind of problem to occur. Therefore, when multiple uncommitted transactions successively make changes to a record, they need to be queued for execution. This queuing process is actually implemented through locks. This so-called lock is actually a structure in memory. There is no lock before the transaction is executed. That is to say, there is no lock structure associated with the record at the beginning, as shown in the figure: When a transaction wants to access this

record When making changes, it will first check whether there is a lock structure associated with this record in the memory. If not, a lock structure will be generated in the memory to associate it with it. For example, if transaction T1 wants to make changes to this record, it needs to generate a lock structure associated with it: the lock structure is related

to the transaction. There are several transactions to operate data, and there are several lock structures.



Summary of several opinions:

1. No locking: This means that there is no need to generate the corresponding lock structure in the memory and the operation can be performed directly.
2. Successful acquisition of the lock, or successful locking: This means that the corresponding lock structure is generated in the memory, and the is_waiting attribute of the lock structure is false, which means that the transaction can continue to perform operations.
3. Failed to acquire the lock, or failed to add the lock, or did not acquire the lock: This means that the corresponding lock is generated in the memory, but the attribute of the lock structure is true, which means that the transaction needs to wait and the operation cannot continue.

read-write or write-read situation

Read-write or write-read, that is, one transaction performs the read operation and the other performs the modification operation. In this case, problems such as dirty reads, non-repeatable reads, and phantom reads may occur. Each database vendor may have different support for the SQL standard. For example, MySQL has solved the phantom read problem at the REPEATABLE READ isolation level.

Solutions to concurrency problems

How to solve the problems of dirty reads, non-repeatable reads, and phantom reads? There are actually two optional solutions:

1. Solution 1: Read operations use multi-version concurrency control (MVCC, explained in the next chapter), and write operations are locked.
   

Ordinary SELECT statements use MVCC to read records under the READ COMMITTED and REPEATABLE READ isolation levels.

1. Under the READ COMMITTED isolation level, a ReadView will be generated every time a SELECT operation is performed during the execution of a transaction. The existence of ReadView itself ensures that the transaction cannot read changes made by uncommitted transactions, which means that it avoids Dirty read phenomenon;
2. Under the REPEATABLE READ isolation level, only the first SELECT operation performed during a transaction will generate a ReadView. Subsequent SELECT operations will reuse this ReadView, thus avoiding the problems of non-repeatable reads and phantom reads.

2. Option 2: Locking is used for both reading and writing operations.
   

Summary of comparison findings:

1. If the MVCC method is used, read-write operations do not conflict with each other and the performance is higher.
2. If locking is used, read-write operations need to be queued to execute each other, which affects performance.

Under normal circumstances, we are of course willing to use MVCC to solve the problem of concurrent execution of read-write operations, but in some special circumstances, the business requires locking to be executed. The following explains the different types of locks in MySQL.

Different angle classifications of locks

The classification diagram of locks is as follows:

Divided by type of data operation: read lock, write lock

Read lock: also called shared lock, represented by S in English. For the same data, multiple transaction read operations can be performed simultaneously without
affecting each other and without blocking each other.
Write lock: also called exclusive lock, represented by X in English. It will block other write locks and read locks before the current write operation is completed. This
ensures that only one transaction can perform writes at a given time and prevents other users from reading the same resource being written to.

It should be noted that for the InnoDB engine, read locks and write locks can be added to the table or rows.

Lock read

write operation

The commonly used write operations are nothing more than delete, update, and insert.