mysql database transaction feature isolation level

⑴ Atomicity (Atomicity) Atomicity
　　 means that all operations included in the transaction either all succeed or all fail to be rolled back. This is the same concept as the function of the transaction introduced in the previous two blogs, so the operation of the transaction must be complete if it is successful. Applied to the database, it must not have any effect on the database if the operation fails.

⑵ Consistency (Consistency)
　　 Consistency means that the transaction must make the database change from one consistent state to another consistent state, that is to say, a transaction must be in a consistent state before and after execution.

　　Take the transfer as an example, assuming that the sum of the money of user A and user B is 5,000, then no matter how the money is transferred between A and B, after several transfers, the sum of the money of the two users should be returned after the transaction is over. is 5000, which is the consistency of the transaction.

(3)
　　 Isolation is that when multiple users access the database concurrently, such as when operating the same table, the transaction opened by the database for each user cannot be interfered by the operations of other transactions. isolated from each other.

　　That is to achieve such an effect: for any two concurrent transactions T1 and T2, in the view of transaction T1, T2 either ends before T1 starts, or starts after T1 ends, so that each transaction does not feel until there are other transactions executing concurrently.

　　Isolation on Transactions Databases offer a variety of isolation levels, which will be described later.

⑷ Durability Durability
　　 means that once a transaction is committed, the changes to the data in the database are permanent, and the operation of committing the transaction will not be lost even if the database system encounters a failure.

　　For example, when we use JDBC to operate the database, after submitting the transaction method, the user is prompted that the transaction operation is completed. When our program execution is completed until we see the prompt, we can determine the transaction and submit it correctly. Even if there is a problem with the database at this time, we must We need to complete our transaction completely, otherwise we will see a major error indicating that the transaction is completed, but the database failed to execute the transaction because of the failure.

 

　　The four characteristics of transactions (ACID for short) have been introduced above. Now we will focus on the isolation of transactions. When multiple threads open transactions to operate data in the database, the database system must be able to perform isolation operations to ensure that each thread obtains The accuracy of the data, before introducing the various isolation levels provided by the database, let's take a look at several problems that will occur if the isolation of the transaction is not considered:

1. Dirty reads
　　 Dirty reads refer to reading in a transaction process Fetched data from another uncommitted transaction.

　　When a transaction is modifying a certain data multiple times, and these multiple modifications have not been committed in this transaction, then a concurrent transaction accesses the data, which will cause the data obtained by the two transactions to be inconsistent. For example: user A transfers 100 yuan to user B, the corresponding SQL command is as follows

    update account set money=money+100 where name='B'; (At this time, A informs B)

    update account set money=money - 100 where name='A ';
　　When only the first SQL is executed, A notifies B to check the account, and B finds that the money has indeed arrived (a dirty read occurs at this time), and then no matter whether the second SQL is executed or not, as long as the transaction is not submitted, Then all operations will be rolled back, and when B checks the account again later, he will find that the money has not actually been transferred.

2. Non-repeatable read
　 　Non-repeatable read means that for a certain data in the database, multiple queries within the scope of a transaction return different data values. This is because it is modified and committed by another transaction during the query interval.

　　For example, transaction T1 is reading a certain data, and transaction T2 immediately modifies the data and submits the transaction to the database. Transaction T1 reads the data again and obtains a different result, sending a non-repeatable read.

　　The difference between a non-repeatable read and a dirty read is that a dirty read is a transaction that reads uncommitted dirty data of another transaction, while a non-repeatable read is a read of the data submitted by the previous transaction.

　　In some cases, non-repeatable reading is not a problem. For example, when we query a certain data multiple times, of course, the results obtained by the last query are the main ones. But in other cases, problems may occur. For example, for the same data, A and B may be queried in sequence, and A and B may fight...

3. Phantom reading (phantom reading)
　　 Phantom reading is that transactions are not independent A phenomenon that occurs during execution. For example, transaction T1 modifies a data item of all rows in a table from "1" to "2". At this time, transaction T2 inserts a row of data item into this table, and the value of this data item Still "1" and committed to the database. If the user who operates transaction T1 checks the data just modified, he will find that there is one row that has not been modified. In fact, this row is added from transaction T2, as if hallucinations occur. This is a hallucination reading.

　　Both phantom reads and non-repeatable reads read another committed transaction (this is different from dirty reads), the difference is that non-repeatable reads query the same data item, while phantom reads target a batch of The data as a whole (such as the number of data).



　　Now let's take a look at the four isolation levels provided by the MySQL database:

　　① Serializable (serialization): It can avoid the occurrence of dirty reads, non-repeatable reads, and phantom reads.

　　② Repeatable read: It can avoid the occurrence of dirty reads and non-repeatable reads.

　　③ Read committed (read committed): to avoid the occurrence of dirty reads.

　　④ Read uncommitted (read uncommitted): the lowest level, no guarantee under any circumstances.



　　The highest of the above four isolation levels is the Serializable level, and the lowest is the Read uncommitted level. Of course, the higher the level, the lower the execution efficiency. A level like Serializable uses a lock table (similar to the lock in Java multi-threading) so that other threads can only wait outside the lock, so the isolation level usually selected should be based on the actual situation. The default isolation level in MySQL databases is Repeatable read.

　　In the MySQL database, the above four isolation levels are supported, and the default is Repeatable read; in the Oracle database, only the Serializable (serialization) level and the Read committed (read committed) level are supported. , the default is Read committed level.

　　View the isolation level of the current transaction in the MySQL database:

    select @@tx_isolation;
　　Set the isolation level of the transaction in the MySQL database:

    set [glogal | session] transaction isolation level isolation level name;

    set tx_isolation='isolation level name;'
Example 1 : View the isolation level of the current transaction:

　　

Example 2: Set the isolation level of the transaction to the Read uncommitted level:

　　

Or:

　　

Remember: The isolation level of the database must be set before the transaction is opened!

　　If JDBC is used to set the isolation level for database transactions, it should also be called before the setAutoCommit(false) method of the Connection object. Call setTransactionIsolation(level) of the Connection object to set the isolation level of the current link. As for the parameter level, you can use the fields of the Connection object:

　　

Part of the code for setting the isolation level in JDBC:

　　

　　Postscript: The setting of the isolation level is only valid for the current link. For using the MySQL command window, a window is equivalent to a link, and the isolation level set by the current window is only valid for the transaction in the current window; for JDBC operating the database, a Connection object is equivalent to a link, and for the Connection object The set isolation level is only valid for this Connection object and has nothing to do with other linked Connection objects.