MySQL four transactions

What is a transaction? How are transactions implemented?

"Shallow entry and deep exit" the realization of transactions in MySQL

What are the four major transaction characteristics (ACID) of MySQL?

  • Atomicity: Transaction is the smallest unit of execution and division is not allowed. The atomicity of the transaction ensures that the actions are either all completed or completely ineffective;
  • Consistency: The data is consistent before and after the transaction is executed. For example, in the transfer business, the total amount of the transferor and the payee should be the same regardless of whether the transaction is successful or not;
  • Isolation: When concurrently accessing the database, a user's transaction is not interfered by other transactions, and the database is independent among concurrent transactions;
  • Persistence: After a transaction is committed. Its changes to the data in the database are persistent, and even if the database fails, it should not have any impact on it.

What is dirty read? Phantom reading? What is the difference between dirty reading and phantom reading? How to solve dirty reading and phantom reading?

In a typical application, multiple transactions run concurrently, often operating the same data to complete their tasks (multiple users operate on unified data). Although concurrency is necessary, it may cause the following problems.

  • Dirty read: When a transaction is accessing data and modifies the data, and this modification has not yet been committed to the database, another transaction also accesses the data and then uses the data. Because this data is data that has not yet been committed, the data read by another transaction is "dirty data", and the operation based on "dirty data" may be incorrect.
  • Lost to modify: Refers to when a transaction reads a data, another transaction also accesses the data, then after the data is modified in the first transaction, the second transaction also modifies the data. In this way, the result of the modification in the first transaction is lost, so it is called a lost modification. For example: Transaction 1 reads the data A=20 in a table, transaction 2 also reads A=20, transaction 1 modifies A=A-1, transaction 2 also modifies A=A-1, the final result A=19, transaction The modification of 1 is lost.
  • Unrepeatableread: Refers to reading the same data multiple times in a transaction. Before this transaction is over, another transaction also accesses the data. Then, between the two read data in the first transaction, the data read twice in the first transaction may be different due to the modification of the second transaction. This happens when the data read twice in a transaction is different, so it is called non-repeatable read.
  • Phantom read: Phantom read is similar to non-repeatable read. It occurs when a transaction (T1) reads a few rows of data, and then another concurrent transaction (T2) inserts some data. In the subsequent query, the first transaction (T1) will find that there are more records that do not exist originally, as if an illusion has occurred, so it is called a phantom reading.

The difference between dirty reading and phantom reading:

不可重复读的重点是修改,幻读的重点在于新增或者删除。

Example 1 (The same conditions, the data you have read, read it again and find that the value is different): Mr. A in transaction 1 has not completed the operation of reading his salary as 1000, Mr. B in transaction 2 Modified A's salary to 2000, which caused A to read his salary again when his salary was changed to 2000; this is not repeatable reading.

Example 2 (The same conditions, the number of records read out for the first time and the second time is different): Suppose there are 4 people in a payroll table whose salary is greater than 3000, transaction 1 reads all the people whose salary is greater than 3000, a total of Four records were found. At this time, transaction 2 inserted another record with a salary greater than 3000. When transaction 1 read it again, the number of records found became 5, which led to phantom reading.

How to solve dirty reads?

An exclusive lock is added when modifying, and it is not released until the transaction is committed. After a shared lock is added when reading (so that other transactions will not modify the data while transaction 1 reads the data), no transaction is allowed to manipulate the data , Can only be read, after 1 if there is an update operation, it will be converted to an exclusive lock, and other transactions have no right to participate in reading and writing, thus preventing the dirty read problem.

How to solve the phantom reading?
The RR level under the mvcc mechanism in mysql cannot solve the phantom reading
https://my.oschina.net/u/4407031/blog/4329009
https://database.51cto.com/art/201905/597093.htm

Talk about the isolation level of the transaction? MySQL's default isolation level? The SQL standard defines four isolation levels:

  • READ-UNCOMMITTED (read uncommitted): The lowest isolation level, allowing to read uncommitted data changes, which may cause dirty reads, phantom reads or non-repeatable reads .
  • READ-COMMITTED (read committed): Allows to read data that has been committed by concurrent transactions, which can prevent dirty reads, but phantom reads or non-repeatable reads may still occur .
  • REPEATABLE-READ (repeatable read): The results of multiple reads of the same field are consistent, unless the data is modified by the transaction itself, which can prevent dirty reads and non-repeatable reads, but phantom reads may still occur .
  • SERIALIZABLE (serializable): The highest isolation level, fully compliant with the ACID isolation level. All transactions are executed one by one, so that there is no interference between transactions, that is, this level can prevent dirty reads, non-repeatable reads, and phantom reads .
Isolation level Dirty read Non-repeatable Phantom reading
READ-UNCOMMITTED
READ-COMMITTED ×
REPEATABLE-READ × ×
SERIALIZABLE × × ×

The default isolation level supported by the MySQL InnoDB storage engine is REPEATABLE-READ (re- readable )

Guess you like

Origin blog.csdn.net/weixin_44533129/article/details/112966892