[Database] Comparison of transaction isolation levels between Oracle and Mysql

Brief introduction: four characteristics of transactions (ACID)

Transactions have four characteristics: Atomicity, Consistency, Isolation and Durability. These four features are referred to as ACID features for short.

1. Atomicity. The transaction is the logical unit of work of the database, all operations contained in the transaction are either done or not done

2. Consistency. The result of transaction execution must be to make the database from a consistent state to another consistent state. Therefore, when the database only contains the results of successful transaction submission, the database is said to be in a consistent state. If a failure occurs during the operation of the database system, some transactions are forced to be interrupted before they are completed. Some of the modifications made to the database by these unfinished transactions have been written to the physical database. At this time, the database is in an incorrect state, or Inconsistent state.

3. Isolation. The execution of a transaction cannot interfere with other transactions. That is, the internal operations and data used by a transaction are isolated from other concurrent transactions, and each transaction executed concurrently cannot interfere with each other.

4. Sustainability. Also called permanent, it means that once a transaction is committed, its changes to the data in the database should be permanent. The following other operations or failures should not have any influence on the results of its execution.

Four isolation levels of Mysql

The SQL standard defines 4 types of isolation levels, including some specific rules to limit which changes inside and outside the transaction are visible and which are invisible. Note here: low-level isolation levels generally support higher concurrent processing and have lower system overhead.

Read Uncommitted (read uncommitted content)

At this isolation level, all transactions can see the execution results of other uncommitted transactions. This isolation level is rarely used in practical applications, because its performance is not much better than other levels. Reading uncommitted data is also called dirty read (Dirty Read).

Read Committed (read submitted content)

This is the default isolation level for most database systems (but not the MySQL default). It satisfies the simple definition of isolation: a transaction can only see the changes made by the committed transaction. This isolation level also supports the so-called non-repeatable read (Nonrepeatable Read), because other instances of the same transaction may have new commits during the processing of the instance, so the same select may return different results.

Repeatable Read

This is MySQL's default transaction isolation level, which ensures that multiple instances of the same transaction will see the same data rows when reading data concurrently. But in theory, this leads to another thorny problem: Phantom Read. Simply put, phantom reading means that when the user reads a range of data rows, another transaction inserts a new row in the range. When the user reads the data rows in the range again, they will find new " Phantom" line. The InnoDB and Falcon storage engines solve this problem through the Multiversion Concurrency Control (MVCC) mechanism.

Serializable (Serializable)

This is the highest isolation level, which solves the problem of phantom reading by forcing transaction ordering to make it impossible to conflict with each other. In short, it adds a shared lock on each row of data read. At this level, it may lead to a large number of timeouts and lock contention.

Problems caused by different isolation levels

These four isolation levels are implemented by using different lock types. If the same data is read, problems are prone to occur. E.g:

Dirty Read: A transaction has updated a copy of data, and another transaction has read the same copy of data at this time. For some reason, if the previous RollBack operation is performed, the data read by the next transaction is Would be incorrect.

Non-repeatable read: The data is inconsistent in the two queries of a transaction. This may be the original data updated by a transaction inserted between the two queries.

Phantom Read: The number of data items in the two queries of a transaction is inconsistent. For example, one transaction queries several rows of data, while another transaction inserts new columns of data at this time. In the next query, you will find that there are several columns of data that it did not have before.

In MySQL, these four isolation levels are implemented, which may cause problems as follows:

Oracle's transaction isolation level

There are two Oracle transaction isolation levels:

(1) READ COMMITTED: Read has been submitted

(2) SERIALIZABLE: serial read

The default isolation level is: READ COMMITTED

View the default isolation level: you can view and verify through the dbms_transaction package and the v$transaction view:

--First create a transaction declare trans_id Varchar2(100); begin trans_id := dbms_transaction.local_transaction_id( TRUE ); end; --View transaction isolation level SELECT s.sid, s.serial#,CASE BITAND(t.flag, POWER( 2, 28)) WHEN 0 THEN'READ COMMITTED' ELSE'SERIALIZABLE ' END AS isolation_levelFROM v $transactiontJOINv$session s ON t.addr = s.taddr AND s.sid = sys_context(‘USERENV’, ‘SID’);设置隔离级别命令： SET TRANSACTION ISOLATION LEVEL [READ COMMITTED|SERIALIZABLE]

There are four isolation levels of MySql database

The default isolation level is: REPEATABLE-READ (repeat read);

View the default isolation level: select @@tx_isolation;

Set isolation level command: set global transaction isolation level repeatable read;

That’s it for sharing this issue, see you next time~~~