Mysql transaction isolation mechanism

ACID principles:

Learn Mysql transaction isolation mechanism first need to understand what is ACID:

  1. A: atomic automicity, a transaction as indivisible minimum unit, all operations inside a transaction either all succeed or all fail.
  2. C: consistency consistency, after the system state of things is the same, that data can not be generated for no reason, no reason not to disappear, for example, a transfer of business affairs, eventually all account balances unchanged.
  3. I: isolation isolation, simply speaking, a firm operating there, before the final Commit, all the changes are not visible to other transactions
  4. D: Persistent durability, when the transaction is committed, the data should be stored permanently in the data, even catastrophic consequences, the data will not be lost

Mysql database isolation level:

ACID achieved under actual use situation is very difficult, but the performance will be greatly reduced, often different business requirements of affairs is not the same, so in order to improve performance and meet business database provides four different levels of isolation for users to select

  1. Uncommitted Read (Read UNCOMMITTED): this level, when a transaction to modify the data, even if not submitted, will be read to the other matters, easy to produce a highly concurrent state dirty read.
  2. Read Committed (READ COMMITTED): the entire operation in a transaction, all data modifications are not visible to other transactions, but in this case leads to other non-repeatable read transaction is generated (i.e. two read inconsistent results) this level is also called non-repeatable read
  3. Repeatable Read (REPEATABLE READ):Mysql default transaction isolation levelThe level can ensure that a transaction throughout the process, read many of the same results the same record, but does not solve the problem of phantom reads.
  4. Serialization (SERIALIZABLE): it is the highest transaction isolation level, all on the same read and write will block a table, each need to get table-level shared lock

Question multiple transactions data generated under which:

  1. Dirty Read: Transaction A Transaction B reads to modify another uncommitted transaction rollback B modified, Transaction A reads a dirty read.
  2. Non-repeatable read: A transaction C reads the record, in this process the recorded transaction B C modification field to modify, when the transaction record C A read again, the results obtained with the different first, called unrepeatable read.
  3. Reading Magic: Magic reading in similar non-repeatable read, when the transaction A first reading of a range of recording time, a new record transaction B, A transactions in this range will read this one more record results in phantom read occurs

Different transaction isolation level respectively solve any problems

Isolation Levels Dirty read Non-repeatable read Magic Reading
Uncommitted Read (Read UNCOMMITTED) presence presence presence
Read Committed (READ COMMITTED) does not exist presence presence
Repeatable Read (REPEATABLE READ) does not exist does not exist presence
Serializable (SERIALIZABLE) does not exist does not exist does not exist

Mysql Affairs commonly used commands:

Interested students can open several Sql command interface, try the above scenario, the following are some common transaction sql:

SELECT @@tx_isolation;  -- 查询当前隔离机制

begin; -- 开始事务

rollback; -- 回滚

commit; -- 提交

-- 设置当前会话隔离级别
set session transaction isolation level read uncommitted; -- 未提交读
set session transaction isolation level read committed; -- 已提交读
set session transaction isolation level repeatable read; -- 可重复读
set session transaction isolation level serializable; -- 可串行化

-- 设置系统隔离级别
set global transaction isolation level read uncommitted; -- 未提交读
set global transaction isolation level read committed; -- 已提交读
set global transaction isolation level repeatable read; -- 可重复读
set global transaction isolation level serializable; -- 可串行化

The above is only superficial understanding of bloggers, we have a better suggestion, please leave a message, bloggers will promptly correct! ! !

Guess you like

Origin blog.csdn.net/zhangyong01245/article/details/93888868