Mysql-depth understanding of the transaction

As developers of database transactions should not unfamiliar, but if you know the how but not the why, then, in development will inevitably write the code exists bug, this article introduces mysql affairs to highlight the isolation level of the transaction.

1. ACID

1.1 Atomicity

Atomicity means that a transaction is an indivisible unit of work, all operations in the transaction either executed or not executed all.
For example:
the begin // Open Transaction
A: Update User SET = Account Account WHERE ID = +. 1. 1;
B: SET Update User Account = Account WHERE ID = +. 1. 1;
the commit
of this transaction, the commit is executed, two statements in it They are executed successfully, if an error occurs, the implementation of rollback, the two statements are rolled back to its original state;

undo log guarantee the atomicity of
the data before any operation, backup data to a first place (this is the place to store undo log data). Then modify the data, and if an error has occurred or user user performs a rollback statement, using the data available to the system undo log backup is restored to the state before the transaction began.
Note: undo log is the logical logs
can be understood as:

  • When a record delete, undo log records in a record corresponding to the insert
  • When a record insert, undo log records will delete a record corresponding to the
  • When an update record, which records a record corresponding to the opposite udpate

    1.2 Consistency

    Before and after transaction execution and transaction execution, integrity constraints of the database is not destroyed. I.e., execution of the transaction is transferred from one active state to another active state;
    for example:
    tom to the transfer jack 50, if the account tom reduced from a system failure or other reason, not coupled to the jack 50, and the transaction has not been completed yet , the entire transfer process will roll back the database to ensure data consistency;

    1.3 Isolation

    Isolation refers to the concurrent operation, different transaction should isolate each of the concurrent transactions do not interfere with each other;

    1.4 endurance of

    Once the transaction is submitted successfully, all transaction data manipulation must be saved to the database persist, even after the transaction is committed, the database crashes, when the database is restarted, it must be able to guarantee the recovery of data by some mechanism.
    redo log to ensure the durability of
    redo log record new data is backed up, before the transaction is committed, as long as the redo log persistent, do not need the data persistence. When the system crashes, although the data are not persistent, but redo log has been persistent, the system can be based on the contents of redo log, all data will be restored to the latest state.

    2. affairs issues arising

    The above describes the characteristics of the database transaction, in which isolation, we need to explain the focus of this article, set the level of isolation between different database transaction, the transaction will resolve the concurrency issues. So said the following about what issues the transaction will lead to:

2.1 dirty read

A read transaction to transaction B has been modified but not yet committed, rolled back if the transaction B, A reads data with previous inconsistent; do not meet the conformance requirements affairs;
for example: A (left) and B (Fig. Right) while turning the transaction, a execute the following command:
Mysql-depth understanding of the transaction
user a does not commit the transaction, visible results in two queries in transaction B has changed, the data is read transaction a uncommitted;

2.2 Non-repeatable read

A read transaction to the transaction data modification B has been submitted, does not meet the isolation;
Mysql-depth understanding of the transaction
The figure shows, transaction B A modified transaction data;

2.3 Magic Reading

A read transaction to the new transaction data submitted by B, does not meet the isolation;
Mysql-depth understanding of the transaction
transaction B to A new transaction data submitted;

3. In-depth isolation level

Isolation level rating:
Mysql-depth understanding of the transaction

View isolation level:

show variables like '%isolation%';
SELECT @@GLOBAL.transaction_isolation, @@transaction_isolation;

Setting the isolation level:

全局:SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;
会话:SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

3.1 Uncommitted Read

Uncommitted Read is the lowest level of the database transaction isolation level, it does not solve any problems;
set the database transaction isolation level to read uncommitted

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

Mysql-depth understanding of the transaction

3.2 Read Committed

Read Committed mainly solves the problem of dirty reads;
set the database transaction isolation level to read already paid

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
Mysql-depth understanding of the transaction
it can be seen, read has been submitted already solved the problem of dirty read;

3.3 Repeatable Read

Set the transaction isolation level:

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

Mysql-depth understanding of the transaction
We can see, even if the transaction has been submitted A, B transaction would no longer read A transaction data submitted;
so repeatable read fix the phantom read it?
We try it:
Mysql-depth understanding of the transaction
This is how it happened? Not to say good repeatable read does not solve the problem of phantom read it? Why this new data is inserted in a transaction not read it in B? (Under section answers)

3.4 serialization

Serialization is not to say, it is actually handled by the transaction queuing, but it would be very low transaction rate.

4. mysql of MVCC

Let's look at an example:
Mysql-depth understanding of the transaction
As can be seen from the above process execution, after the transaction commits A, B, although the transaction is not a problem when the query is executed, but after performing the update transaction B, when the query again, less than 100 accounts directly; this Why?

1) MVCC principle

InnoDB is MVCC achieved by the end of each two rows hidden fields, the version number and version number of the deleted when creating. Each transaction begins the version number is incremented.
SELECT:

  • Find a version earlier than the current transaction version of the row, that is, the system version number of the line system version number less than or equal transactions, ensuring that the transaction row is read, is before the start of the transaction or the existing operating over their own affairs .
  • Deleted version of the line, either undefined or greater than the version number of the current transaction, so you can ensure that the transaction to read a row, has not been removed before the start of the transaction;
    INSERT:
    for each row inserted to save the current system version number as the row version No;
    dELETE:
    delete each row to save the current system version number as marked for deletion;
    UPDATE:
    insert a new row record, save the current system version number is the version number of the line, at the same time, save the current system version number to identify the original delete rows;

2) a snapshot of the current reading and reading

Snapshots read:
reading is a snapshot version, which is the version of history; general reading of select is a snapshot of
the current read:
read the latest version, update, delete, insert, select ... lock in share mode, select ... for update is currently reading;

Section 3.3 puzzled answer
Transaction A performing the update, submitted affairs, and when the transaction B again to perform the update, it is actually a current read, the latest data has been modified to be able to read transaction A (A prerequisite for the transaction has been submitted ).

3) undo log version in the chain and ReadView

This content is more complex, you can refer to:
https://blog.csdn.net/shenchaohao12321/article/details/92801779

Guess you like

Origin blog.51cto.com/13733462/2453460