Are double reads a possibility in InnoDB - mysql

Question

Can concurrency effects called "Missing and Double Reads Caused by Row Updates" and mentioned here https://msdn.microsoft.com/en-us/en-en/library/ms190805.aspx be relevant for Innodb engine?
ex.:
Transactions that are running at the READ UNCOMMITTED level do not issue shared locks to prevent other transactions from modifying data read by the current transaction. Transactions that are running at the READ COMMITTED level do issue shared locks, but the row or page locks are released after the row is read. In either case, when you are scanning an index, if another user changes the index key column of the row during your read, the row might appear again if the key change moved the row to a position ahead of your scan. Similarly, the row might not appear if the key change moved the row to a position in the index that you had already read. To avoid this, use the SERIALIZABLE or HOLDLOCK hint, or row versioning
And one more update. From MSSQL engine:
"Inside Microsoft SQL Server 2008"
In certain circumstances, scans can end up returning multiple occurrences of rows or even skip rows. Allocation order scans are more prone to such behavior than index order scans. I’ll fi rst describe how such a phenomenon can happen with allocation order scans and in which circumstances. Then I’ll explain how it can happen with index order scans. Allocation Order Scans Figure 4-30 demonstrate in three steps how an allocation order scan can return multiple occurrences of rows. Step 1 shows an allocation order scan in progress, reading the leaf pages of some index in fi le order (not index order). Two pages were already read (keys 50, 60, 70, 80, 10, 20, 30, 40). At this point, before the third page of the index is read, someone inserts a row into the table with key 25. Step 2 shows a split that took place in the page that was the target for the insert since it was full. As a result of the split, a new page was allocated—in our case later in the fi le at a point that the scan did not yet reach. Half the rows from the original page move to the new page (keys 30, 40), and the new row with key 25 was added to the original page because of its key value. Step 3 shows the continuation of the scan: reading the remaining two pages (keys 90, 100, 110, 120, 30, 40) including the one that was added because of the split. Notice that the rows with keys 30 and 40 were read a second time..

Answer 1

This may be relevant to InnoDB engine in some circumstances.
For InnoDB, with SELECT queries issued in READ COMMITTED and REPEATABLE READ transaction isolation levels a Consistent Read mode is used, which is an implementation of MVCC otherwise known as optimistic concurrency. Under this mode, the reading query doesn't issue any locks but instead the engine maintains a snapshot of the database as it was when the query begun. No changes outside of that query are visible to it until it is committed (or entire transaction depending which of the above two isolation levels was chosen).
Is such scenario the situation you describe in your question would not be possible.
Example from the MySQL manual section lined above:
Session A Session B
SET autocommit=0; SET autocommit=0;
time
| SELECT * FROM t;
| empty set
| INSERT INTO t VALUES (1, 2);
|
v SELECT * FROM t;
empty set
COMMIT;
SELECT * FROM t;
empty set
COMMIT;
SELECT * FROM t;
---------------------
| 1 | 2 |
---------------------
1 row in set
Reading queries issued under READ UNCOMMITTED transaction isolation level bypass MVCC and "see" everything that is happening in the database, including any uncommitted transactions. This makes phantom and dirty reads an issue.
Reading queries relying on explicit use of locks (SELECT... FOR UPDATE and SELECT... LOCK IN SHARED MODE) or querying under SERIALIZABLE isolation level automatically falls back to locking-based concurrency. The latter upgrading any SELECT query to LOCK IN SHARED MODE. In this particular case whether you're safe from data movement as described in your question is dependent on the SELECT query WHERE predicates you have used. This impacts whether the engine locks only data you have just read or also entire ranges between the data you have read. Following is an excerpt from the relevant manual page:
For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), UPDATE, and DELETE statements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it. For other search conditions, InnoDB locks the index range scanned, using gap locks or next-key (gap plus index-record) locks to block insertions by other sessions into the gaps covered by the range.