"MySQL Practical Combat 45 Lectures" Course Study Notes (3)

transaction isolation

  • A transaction is to ensure that a set of database operations either all succeed or all fail.

Isolation and Isolation Levels

  • Transaction characteristics: ACID (Atomicity, Consistency, Isolation, Durability, that is, atomicity, consistency, isolation, and durability).
  • When multiple transactions are executed on the database at the same time, problems such as dirty reads, non-repeatable reads, and phantom reads may occur. In order to solve these problems, there is a " The concept of "isolation level".
  • SQL standard transaction isolation levels include: read uncommitted (read uncommitted), read committed (read committed), repeatable read (repeatable read) and serializable (serializable).
    • Read uncommitted means that when a transaction has not been committed, the changes it makes can be seen by other transactions.
    • Read commit means that after a transaction is committed, the changes it makes will be seen by other transactions.
    • Repeatable reading means that the data seen during the execution of a transaction is always consistent with the data seen when the transaction was started.
    • Serialization, as the name implies, is for the same line of records, "write" will add "write lock", "read" will add "read lock". When a read-write lock conflict occurs, the later accessed transaction must wait for the previous transaction to complete before continuing to execute.
  • In terms of implementation, a view will be created in the database, and the logical result of the view shall prevail when accessing.
    • Under the "repeatable read" isolation level, this view is created when the transaction starts, and this view is used throughout the existence of the transaction.
    • Under the "read committed" isolation level, this view is created at the beginning of each SQL statement execution.
    • It should be noted here that under the "read uncommitted" isolation level, the latest value on the record is directly returned, and there is no view concept; while under the "serialization" isolation level, locking is directly used to avoid parallel access.
  • The default isolation level of the Oracle database is actually "read committed".
    • For some applications migrating from Oracle to MySQL, in order to ensure the consistency of the database isolation level, you must remember to set the MySQL isolation level to "read committed".
    • The configuration method is to set the value of the startup parameter transaction-isolation to READ-COMMITTED.

Implementation of transaction isolation

  • In MySQL, each record actually records a rollback operation when it is updated. The latest value on the record, through the rollback operation, can get the value of the previous state.
    insert image description here
    • The same record can have multiple versions in the system, which is the multi-version concurrency control (MVCC) of the database.
    • The system will judge when there are no transactions that need to use these rollback logs, that is, when there is no read-view earlier than this rollback log in the system. , the rollback log will be deleted.

How the transaction is started

  • An explicit start transaction statement, begin or start transaction. The matching commit statement is commit, and the rollback statement is rollback.
  • set autocommit=0, this command will turn off the automatic submission of this thread. It means that if you only execute a select statement, the transaction is started and will not be automatically committed. This transaction persists until you actively execute a commit or rollback statement, or disconnect.
  • Therefore, it is recommended that you always use set autocommit=1 to start transactions with explicit statements.
  • You can query long transactions in the innodb_trx table of the information_schema library.

view

  • If it is a repeatable read isolation level, a view read-view will be created when transaction T starts, and then during the execution of transaction T, even if other transactions modify the data, what transaction T sees is still the same as that seen at startup.
  • In MySQL, there are two concepts of "views":
    • view。
      • It is a virtual table defined with a query statement, which executes the query statement and generates results when called.
      • The syntax for creating a view is create view ... , and its query method is the same as that of a table.
    • consistent read view。
      • Consistent read view used by InnoDB when implementing MVCC.
      • It is used to support the implementation of RC (Read Committed, Read Committed) and RR (Repeatable Read, Repeatable Read) isolation levels.
      • It has no physical structure and is used to define "what data can I see" during transaction execution.

snapshot

  • Under the repeatable read isolation level, the transaction "takes a snapshot" when it starts.
    insert image description here

    • Note that this snapshot is based on the entire library.
    • Each transaction in InnoDB has a unique transaction ID, called transaction id.
      • It is applied to InnoDB's transaction system at the beginning of the transaction, and it is strictly incremental according to the order of application.
    • Each row of data also has multiple versions.
      • Every time a transaction updates data, a new data version is generated, and the transaction id is assigned to the transaction ID of this data version, which is recorded as row trx_id.
      • At the same time, the old data version should be retained, and in the new data version, there can be information that can be obtained directly.
      • A row of records in the data table may actually have multiple versions (row), and each version has its own row trx_id.
  • According to the definition of repeatable reading, when a transaction starts, you can see all committed transaction results. But later, during the execution of this transaction, updates from other transactions are not visible to it.

    • In terms of implementation, InnoDB constructs an array for each transaction, which is used to save all transaction IDs that are currently "active" at the moment the transaction starts. "Active" means that it has been started but not submitted yet.
    • The minimum value of the transaction ID in the array is recorded as the low water mark, and the maximum value of the transaction ID that has been created in the current system plus 1 is recorded as the high water mark.
    • This view array and the high water mark form the consistent view (read-view) of the current transaction.
    • The visibility rules of the data version are obtained based on the comparison between the row trx_id of the data and the consistency view.
    • InnoDB takes advantage of the feature that "all data has multiple versions" and realizes the ability to "create snapshots in seconds".
  • For the moment when the current transaction starts, a data version of row trx_id has the following possibilities:
    insert image description here

    • If it falls in the green part, it means that this version is a committed transaction or generated by the current transaction itself, and this data is visible;
    • If it falls in the red part, it means that this version is generated by a transaction started in the future, and it is definitely invisible;
    • If it falls in the yellow part, it includes two situations:
      • If the row trx_id is in the array, it means that this version is generated by a transaction that has not yet been committed and is not visible;
      • If the row trx_id is not in the array, it means that this version is generated by the transaction that has been submitted, which can be seen.
  • A data version, for a transactional view, there are three situations except that its own updates are always visible:

    • Versions are not committed and are not visible;
    • The version was committed, but it was committed after the view was created and is not visible;
    • The version has been committed, and it was committed before the view was created, so it is visible.

      Update data is read first and then written, and this read can only read the current value, which is called "current read".

  • How is the repeatable read capability of transactions realized?

    • The core of repeatable reading is consistent read (consistent read);
    • When a transaction updates data, only the current read can be used.
    • If the row lock of the current record is occupied by other transactions, you need to enter the lock waiting.
    • The logic of read commit is similar to the logic of repeatable read. The main difference between them is:
      • Under the repeatable read isolation level, you only need to create a consistent view at the beginning of the transaction, and then other queries in the transaction will share this consistent view;
      • Under the read-committed isolation level, a new view is recalculated before each statement is executed.

Guess you like

Origin blog.csdn.net/fangzhan666/article/details/132010176