Transaction isolation level of MySQL transactions

         The underlying implementation of transaction isolation level is very complex , In normal development, we will set the isolation level of transactions according to different scenarios . The isolation level of a transaction specifies the data visibility in a transaction 、 Operability 、 lock . The higher the isolation level of the transaction , The system supports lower concurrency , The lower the isolation level , On the contrary, the lower the support .

The isolation level of transactions is divided into ：

Read uncommitted （READ UNCOMMITED）

         Read uncommitted level , The application can read data that is not committed by other transactions . That is, the data not committed by the transaction is visible to other transactions , I.e. dirty reading . As shown in the figure below ：

  Read the submission (READ COMMITED)

         Read submit level , A transaction cannot read data that is not committed by other transactions . Other affairs , The data read again by the transaction may be inconsistent with the data obtained for the first time, that is It can't be read repeatedly , It cannot be read repeatedly because other transactions modify 、 New lead . As shown in the figure below ：

  Repeatable (REPEATABLE READ)

          Repeatable reading solves dirty reading , Ensure that the data read multiple times is consistent , However, during range query, other transaction queries will read the new data of other transactions , That is, unreal reading .MYSQL Through the storage engine MVCC Multi version concurrency control solves the unreal reading problem .

         Repeatable reading is MYSQL Default isolation level . Here's the picture ：

  Serialization (SERIALIZABLE)

          Serialization can solve the problem of unreal reading , But he will read every row of data and lock it , The competitive resources of locks are relatively large .

​​​​​​​

Transaction level