This article takes you to understand the relationship between database isolation level and lock

Preface

What is the relationship between isolation level and database lock?

This article will talk to you about the connection between the two, I hope it will help you!

Talk about the connection between the two

Before we talk in detail, let us remember one sentence: Database transactions have different isolation levels, and different isolation levels use locks differently. The application of locks ultimately leads to the isolation levels of different transactions.

First, let’s understand what four isolation levels are there.

• Read Uncommitted: (Read Uncommitted)
• Read Committed The default isolation level for most databases
• Repeatable-Read (Repeatable-Read) mysql database default level
• Serializable

The specific implementation and differences of the four isolation levels

First of all, programs can be executed concurrently. Similarly, in MySQL, a table can be read and written by two or more processes at the same time, which is no problem.

For example, if there are two processes to read data at this time, there is no problem, so it is allowed. But if one process is in the process of reading a row of data, and another process writes (changes or deletes) data to this row, what will be the result?

Similarly, if two processes both make changes to a row of data at the same time, whose change shall prevail? What the result will be, I don't dare to imagine if the data is destroyed. So there is a conflict at this time.

Since the conflict and finding a solution, who rely on to solve, this time is by locking mechanism to maintain. How to use locks to prevent them from conflicting?

At the beginning of the transaction, an exclusive lock can be added to the row of data to be written. If it is a read operation, a read lock is given to the row of data. After this, when modifying the row of data, no other processes are allowed to perform any operations on the row of data.

When reading the row of data, other processes cannot change it, but can read it. When the reading or writing is completed, the lock is released, and finally commit is submitted. At this time, reading and writing are separated, and writing and writing are separated.

mysql developers to give this conflict resolution program has a name called: read uncommitted : (Read Uncommitted). This is the first isolation of the transaction.

Note: The above process of locking and releasing the lock is maintained by the mysql database itself, without our human intervention

But this degree of isolation is just not enough. See the test results below

1. A modified transaction level is: uncommitted read. And start the transaction, do a query on the user table:

2. Transaction B updates a record:

3. At this time, transaction B has not yet been submitted, and A performs a query within the transaction and finds that the query result has changed:

4. B performs transaction rollback:

5. When A makes another query, the query result is changed back:

According to the experiment: in the transaction of a process, I changed one row of data, but after I modified it, the lock was released. At this time, another process reads the data, and the previous transaction is not yet committed. Yes, until I roll back the data, the data read by another process becomes useless or wrong data.

We usually call this data is called dirty data, this data is read out is called Zang read .

How to do it? Of course, it still depends on the locking mechanism.

It’s nothing more than the location of the lock. Previously, as long as the data was manipulated, the lock was released immediately. Now the lock release location is adjusted to after the transaction is committed. At this time, before the transaction is committed, other processes cannot perform the data on the row. Reading, including any operations.

Then the database gave a name for the database operating rules for this state is called: Read Committed (Read Committed), or you can call non-repeatable read. This is the second isolation of the transaction.

In some cases, non-repeatable reading is not a problem. For example, when we query a certain data multiple times, of course the result of the final query is the main one. But in other cases, problems may occur. For example, the same data A and B may be queried differently, and A and B may fight...

Continue to see the test results below

1. Adjust the isolation to READ-COMMITTED (read submitted content), set the transaction isolation level of A, and enter the transaction to do a query:

2. B starts the transaction and modifies the record:

3. A queries the user table again and finds that the record is not affected:

4. B commits the transaction:

5. A queries the user table again and finds that the record has been modified:

At this point in the experiment, you will find that if the same data is read twice in the same transaction, the final results are inconsistent.

Here we call this phenomenon: non-repeatable reading . Because after the first transaction reads the data, another transaction modifies the data at this time. At this time, the transaction is committed. When the second transaction reads the data for the second time, the result is different. Before a modification Yes, one is revised.

But if you are careful, you will find that since you said that this kind of isolation is to release the lock after the transaction is committed, then in the test process, before the data is not committed, why another transaction can still be read.

Is the above test wrong? no;

Here mysql uses a concurrent version control mechanism, they call it MVCC, in layman's terms: mysql in order to improve the concurrency of the system, before the transaction is not committed, although the data operated within the transaction is locked, but another transactions can still read the data snapshot version ; most databases like Oracle, etc. the default is to read submission of this level of isolation.

But the default isolation level of mysql is not this

And not only does this problem occur when updating data as above, it still causes a similar phenomenon when inserting data: Although mysql locks the data row that is being operated, it still does not prevent another transaction from inserting into the table New row with new data.

For example: a transaction reads or updates all rows in the table, and the receiver has another transaction to insert a new row into the table, after the transaction is committed;

The transaction that originally read or changed the data reads the same data a second time. At this time, the number of rows in the result set read twice in this transaction is different. All the rows were updated, but now I read it and find that there is still one row that has not been updated. This is called phantom reads .

In order to prevent inconsistent data read twice in the same transaction, (including non-rereadable and phantom read), how do you continue to do it next?

MySQL still uses MVCC concurrent version control to solve this problem, or read snapshot data.

Specifically: if there are multiple reads of the same data in a transaction, MySQL will still choose to read the data of the latest committed transaction when it reads it for the first time. After the first time and then read it later, MySQL will take the first time. The read data is the result.

This ensures data consistency when the same transaction reads data multiple times. At this time, this solution is called the mysql: Repeatable read (Repeatable-Read), which is the third isolation above written, mysql is the default isolation level.

Note: Under the repeatable read isolation level, in addition to ensuring the consistency of the read operation, the consistency of the data is also guaranteed during the update operation (current read) to avoid non-repeatable read and phantom read errors;

Specifically: Under the repeatable read isolation level of MySql, data is updated in a transaction, and the transaction is not committed, and another transaction insert is started to insert new data. At this time, it is impossible to insert new data and the insert operation is blocked; why is it blocked? What about blocking?

Because the data is updated when the first transaction (read current), uses row locks + gap lock table locked, the insertion operation of the second transaction is blocked; only after the first transaction commits, The insert operation in the second transaction can be executed;

If it is not blocked, what will be the problem? There will be phantom read problems; for example: would have been a field full table of all the data has been updated, but due to the added data behind these new data field that has not been updated, just like there was when you view again The illusion is the same; so in order to solve the problem of phantom reads, gap locks are provided in the repeatable read isolation level, and row locks + gap locks are used to lock the table so that all operations cannot modify the data.

Note: The innodb storage engine has a configuration for the lock wait timeout period. If the lock is not acquired within the specified time, the transaction is interrupted and the application code needs to be manually rolled back or retryed;

Note: The difference between phantom reading and non-repeatable reading:

• The phantom reading is for a batch of data records as a whole
• Non-repeatable read is for the records of the same data item

At this time, our last isolation level is also the highest isolation level: do not serialize (serializable) debut

The isolation level will automatically lock the data of the entire table you want to operate. If another process transaction wants to manipulate any data in the table, it needs to wait for the process to obtain the lock to complete the operation to release the lock.

Can avoid dirty reads, non-repeatable reads, and phantom reads. Of course, performance will drop a lot, which will cause many processes to queue up to compete for locks.

postscript

The four isolated lock mechanism applications mentioned above are automatically completed by the database without human intervention.

The isolation level setting is only valid for the current session connection. For using the MySQL command window, a window is equivalent to a link, and the isolation level set in the current window is only valid for the transactions in the current window.