MySQL consistent read

Consistent nonlocking Reads

Consistent reading means that InnoDB uses multiple editions to provide a snapshot of the database at a point in time. This kind of query can see changes in transaction commits prior to the current world point, no changes submitted since then, and no uncommitted changes are seen. One exception to this rule is that it can see a change in the same transaction before the query. This exception causes: If you update a row in a table, a select can see the most recent version of the rows that were updated, and it can also see an older version of any row, If another transaction updates the table at the same time, it means that you may see a certain state of the table but this state does not exist in the database.

If the transaction isolation level is Repeatable_read, then all consistent reads in the same transaction will be read to the stable snapshot version that was first read in the transaction. If you commit the current transaction and then execute the same query later, you will get the updated snapshot version.

Consistent read at the read_committed and Repeatable_read isolation levels is the way InnoDB handles select by default. A consistent read does not set any locks on the table it accesses, so the table can be modified at will by other transactions at the same time as a consistent read.

Assuming the transaction isolation level is Repeatable_read, when you perform a consistent read, InnoDB gives your transaction a point in time based on the time you query the database. If another transaction deletes a row after your point in time and commits, you will not see this line because it has been deleted. Insertions and modifications are similar to this.

This is called multi-version concurrency control

In the following example, only if B has submitted its insert and a has also submitted, a to see the insertion of B

Translated from https://dev.mysql.com/doc/refman/5.7/en/innodb-consistent-read.html

MySQL consistent read