Four isolation levels of SQL transactions

Four isolation levels are defined in the SQL standard, each of which specifies the modifications made within a transaction, which are visible within and between transactions, and which are not. Lower levels of isolation can generally perform higher concurrency with lower overhead to the system.

  • Read uncommitted : At the uncommitted read level, changes in a transaction are visible to other transactions even if they are not committed. Transactions can read uncommitted data, also known as dirty reads . This level can cause many problems. In terms of performance, uncommitted reads are not much better than other levels, but they lack many of the benefits of other levels and are generally rarely used in practical applications.
  • Read committed : The default isolation level of most database systems is read committed (but Mysql is not). Committed reads satisfy the simple definition of isolation mentioned earlier: at the beginning of a transaction, only changes made by committed transactions are "see". In other words, any modifications made by a transaction from the start until it is committed are invisible to other transactions. This level is sometimes called nonrepeatable read , because executing the same query twice may yield different results.
  • Repeatable read : Repeatable reads solve the problem of dirty reads. This level ensures that the results of multiple reads of the same record in the same transaction are consistent. But in theory, the repeatable read isolation level still cannot solve another phantom read problem. The so-called phantom read means that when a transaction reads records in a certain range, another transaction inserts new records in the range. When the previous transaction reads the records in this range again, it will Generate a Phantom row . Repeatable read is MySQL 's default transaction isolation level.
  • Serializable : Serializable is the highest isolation level. It avoids the aforementioned phantom read problem by forcing transactions to be executed serially. Simply put, serializability puts a lock on every row of data read, so it can cause a lot of timeouts and lock contention issues. This isolation level is rarely used in practical applications. It is only considered when it is very necessary to ensure data consistency and no concurrency is acceptable.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326937133&siteId=291194637