InnoDB is the default isolation level RR (repeatable read) can be solved dirty reads and non-repeatable read, phantom read but can not solve the problem.Here are the circumstances under mysql innodb RR level
Introduction 1. MVCC
MVCC is a multi-version concurrency control mechanism.
2. MVCC is to solve the problem?
Most MYSQL transactional storage engine, such as, InnoDB, Falcon and PBXT do not use a simple row lock mechanism. In fact, they are MVCC- and multi-version concurrency control to be used together. Everyone should know that the lock mechanism You may control the concurrent operation, but the overhead is large, and MVCC instead of row-level locks can, in most cases, MVCC, to reduce its overhead.It can be used as a variant of row-level locking
============================================
can solve dirty read can not be repeated reading
solve principle:
non-repeatable read:
each user connecting to the database, the database snapshots are seeing a particular moment, before the transaction is not submitted B, a is always read a database snapshot of a particular moment, case B does not read data modification transaction until the transaction commits B, B will read the content of
dirty read:
B did not submit the transaction, a MVCC transaction in accordance with the principles of studying more than this version is submitted in time is updated
3. MVCC to achieve
MVCC is by saving a snapshot of the data at a point in time to achieve. MVCC different storage engines. MVCC to achieve different storage engines is different, there are typically optimistic concurrency and pessimistic concurrency control.
4.MVCC specific implementation analysis
Now, to analyze how the MVCC concurrency control is achieved through our InnoDB is MVCC.
InnoDB is MVCC, is achieved by saving two hidden columns in each row behind the record, the two columns were preserved this line creation time, a saving of time is to delete the line. Here are not storing the actual time value, but the system version number (can be understood as the transaction ID), not the beginning of a new transaction, the system will automatically increment the version number, system version number will be the start time of the transaction as a transaction ID. the following look at REPEATABLE READ isolation level, MVCC specifically how to do.
INSERT
InnoDB为新插入的每一行保存当前系统版本号作为版本号.
第一个事务ID为1；
SELECT
InnoDB会根据以下两个条件检查每行记录:
a.InnoDB只会查找版本早于当前事务版本的数据行(也就是,行的系统版本号小于或等于事务的系统版本号)，这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的.
b.行的删除版本要么未定义,要么大于当前事务版本号,这可以确保事务读取到的行，在事务开始之前未被删除.
只有a,b同时满足的记录，才能返回作为查询结果.
DELETE
InnoDB会为删除的每一行保存当前系统的版本号(事务的ID)作为删除标识.
看下面的具体例子分析:
The focus here ha
MVCC only work in two REPEATABLE READ and READ COMMITTED isolation level. The other two are not compatible with the isolation level and MVCC, because READ UNCOMMITTED always read the latest data line, rather than in line with the current transaction version of the row, but SERIALIZABLE will read all rows locked.
READ COMMITTED (RC): statement-level snapshot size is.
REPEATABLE READ (RR): size snapshot is transaction-level
