"MySQL 45 Lecture Notes" 03. Transaction Isolation: Why can't I see it after you change it?

Hello, everyone, I am a pig who is dominated by cabbage.

A person who loves to study, sleepless and forgets to eat, is obsessed with the girl's chic, calm and indifferent coding handsome boy.

Insert picture description here

This article is the third lecture notes of "MySQL 45 Lectures". Previously, I used my own language to repeat the content. The effect was very good, but it took too much time. I did not finish a lecture in two hours, especially in the current time. Urgently, it is more inappropriate to adopt this method, so the next step is to extract and summarize the content in the form of question and answer to facilitate future review.

I strongly recommend "45 Lectures on MySQL Actual Combat", this column leverages.

Through this lecture, I learned what is a transaction, the characteristics of a transaction, and what problems can be caused by concurrent transactions, resulting in the concept of isolation level, and the realization of isolation level, which involves MVVC, undo log (rollback log).

How the transaction is started, why is it not recommended to use long transactions, and so on.

Transactions are for storage engines. MySQL's native storage engine MyISAM has no transactions. This article is about InnoDB with transactions.

  1. The concept of transaction: Either all succeed or all fail

  2. Transaction characteristics: ACID (Atomicity, Consistency, Isolation, Durability) atomicity, consistency, isolation, durability

    • Atomicity: A transaction is the smallest unit of execution and indivisible.
    • Consistency: The data remains consistent before and after the transaction is executed. For example, when transferring money, the sum of both parties is unchanged.
    • Isolation: When operating the database concurrently, a transaction cannot be interfered by other transactions, and each transaction remains independent.
    • Persistence: After a transaction is committed, its changes to the data in the database are persistent.
  3. What problems do concurrent transactions bring? Dirty read, non-repeatable read, phantom read.

    • Dirty read: A transaction reads data from another uncommitted transaction. If the uncommitted transaction is rolled back, then the previously read data is wrong, which is dirty data.
    • Non-repeatable read: A transaction reads the changed data that has been committed by another transaction . When the same data is read multiple times in a transaction, before the transaction is over, another transaction also accesses the data and commits the modification, which will cause the data read twice in the first transaction to be inconsistent.
    • Phantom read: A transaction reads new data that has been committed by another transaction . Generally, errors occur in the transaction of statistical data.
    • It is easy to confuse non-repeatable reading and phantom reading. The main difference is that the former reads changed data, while the latter reads newly added data. The countermeasures adopted are also different. Non-repeatable reads are for rows and row-level locks can be added. Phantom reads are for tables, and table-level locks are added.
  4. Solving the above problems leads to the concept of isolation level. Of course, the tighter the isolation, the lower the efficiency. The SQL standard isolation levels include read uncommitted, read committed, repeatable read, and serializable.

    • Read uncommitted: When a transaction has not yet been committed, the changes it makes can be seen by other transactions.
    • Read commit: After a transaction is committed, the changes it makes can be seen by other transactions.
    • Repeatable read: The data seen during the execution of a transaction is consistent with the data seen when it is first started.
    • Serialization: As the name implies, for the same row of records, write will be locked, read will also be locked, when the read-write lock conflicts, the latter transaction must wait for the completion of the previous transaction before it can be executed.
  5. The realization of the isolation level:

    The database will create a view, which is based on the logical result of the view when accessed. "Repeatable read" is to create a view when the transaction starts, so in the transaction, the view is used from beginning to end. "Read commit" is created when each SQL statement starts to execute, so you can read the data submitted by other transactions. "Read uncommitted" does not create a view, and directly returns the latest value on the record. Similarly, serialization does not have the concept of view. It uses locking to avoid concurrent access.

Specifically:

In MySQL, in fact, each record will record a rollback operation at the same time when it is updated. The latest value on the record, through the rollback operation, can get the value of the previous state. Transactions started at different times will have different read-views , which also causes the same record to have multiple versions in the system. This is the multi-version concurrency control (MVVC) of the database. These records are recorded in the undo log (rollback log). )in.

This is why the rollback can be used to return to the state before submission.

  1. When will the rollback log be deleted?

    Delete when you don’t need it. In other words, the system will determine that when there are no transactions that need to use these rollback logs, the rollback logs will be deleted.

    When is it not needed anymore? That is when there is no read-view earlier than this rollback log in the system.

  2. Why not use long transactions?

    Long transactions mean that there will be very old transaction views in the system. Since these transactions may access any data in the database at any time, before the transaction is committed, the rollback records that it may use in the database must be retained, which will cause a large amount of storage space to be occupied.

  3. How the transaction is started

    1. Explicitly start the transaction statement, begin or start transaction. The supporting commit statement is commit, and the rollback statement is rollback.
    2. set autocommit=0, this command will turn off the automatic submission of this thread. This means that if you only execute a select statement, the transaction will start and it will not be committed automatically. This transaction continues until you actively execute a commit or rollback statement, or disconnect.

    If you feel that it is too troublesome to begin each time you actively execute commit, you can use commit work and chain, which is to commit the transaction and automatically start the next transaction.

There is a long way to learn, and I will walk with you.

Guess you like

Origin blog.csdn.net/weixin_44226263/article/details/113881500