A brief discussion of MySQL transaction isolation

This article talks about MySQL transaction isolation. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to everyone.

Introduction to transactions

A transaction is a set of atomic sql queries, or a Independent work unit. In short, statements within a transaction either all execute successfully or all fail.

In Mysql, transaction support is implemented at the engine layer, but not all Mysql engines support transactions. For example, the MyISAM engine does not support transactions. This is one of the important reasons why MyISAM was replaced by InnoDB.

When it comes to transactions, we will definitely think of ACID:

• Atomicity

• Consistency

• Isolation

• Durability

Isolation Level

When multiple transactions are executed simultaneously in the database, problems such as dirty reads, non-repeatable reads, and phantom reads may occur because of the transaction isolation level. the concept of.

The SQL standard defines four isolation levels:

1. READ UNCOMMITTED (uncommitted read)

   Modifications in the transaction, even if they have not yet been committed , are visible to other transactions. Transactions can read uncommitted data, also known as dirty read.

2. READ COMMITTED

   After a transaction is submitted, the changes can be seen by other transactions. This level is also called non-repeatable read, because if the same query is executed twice in a transaction, the results may be different.

3. REPEATABLE READ(repeatable read)

   During the execution of a transaction, the data is always consistent with the data seen when the transaction was started. Of course, at this level, uncommitted data changes are also invisible to other transactions.

4. SERIALIZABLE(Serializable)

   For the same row of records, writing and reading will be locked. When a read-write lock conflict occurs, the transaction accessed later must Waiting for the previous transaction to complete before continuing, will cause a lot of timeout and lock contention problems.

In terms of implementation, a view will be created in the database, and the logic of the view shall prevail when accessing.

Under the isolation level of repeatable read, this view is created when the transaction is started, and this view is used during the entire transaction.

Under the isolation level of read submission, this view is created when the SQL statement starts executing.

Under the read uncommitted isolation level, the latest value on the record is returned directly, without the concept of a view.

Under the serialized isolation level, lock directly to avoid parallel access.

The configuration method is to set the startup parameter transaction-isolation to the desired isolation level.

View the current settings:

mysql> show variables like 'transaction_isolation';
+-----------------------+-----------------+
| Variable_name         | Value           |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+
1 row in set (0.00 sec)

In short, existence is reasonable. Different isolation levels are suitable for different scenarios. We should decide based on the business scenario.

Implementation of transaction isolation

In Mysql, in fact, the update of each record will also record a rollback operation. Through the rollback operation, the latest value of the previous state can be obtained.

The system will automatically determine that when there are no more transactions that require rollback logs, the rollback logs will be deleted.

Why it is not recommended to use long transactions:

Long transactions mean that there will be very old transaction views in the system. Since these transactions can access any data in the database at any time, before this transaction is submitted, , the rollback records that may be used in the database must be retained, which will take up a lot of storage space. At the same time, long transactions also occupy lock resources and may bring down the entire library.

How to start the transaction

• Explicitly start the transaction statement, begin or start transaction, submit means commit, return Use rollback.

• set autocommit = 0, this command will turn off the automatic submission of the thread, which means that if a select statement is executed, the transaction will be started and will not be automatically committed until you Actively execute commit or rollback, or disconnect.

My personal suggestion is to explicitly start the transaction through the first method to avoid the occurrence of long transactions.

In the case of set autocommit = 1, if a transaction is explicitly started with begin, if commit is executed, the transaction will be committed. If you execute commit work and chain, the transaction is committed and the next transaction is automatically started, which also saves the overhead of executing the begin statement again.

Query long transactions:

The following statement is to query transactions lasting more than 60s

mysql> select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60;
Empty set (0.00 sec)

To sum up, during the development process, we try to do as little as possible Use long transactions. If it cannot be avoided, ensure that the logical log space is large enough and support dynamic log space growth. Monitor the Innodb_trx table and report a long transaction alarm.

Recommended: "mysql video tutorial"

The above is the detailed content of A brief discussion of MySQL transaction isolation. For more information, please follow other related articles on the PHP Chinese website!