问题
I tried this with MySQL Server 5.5:
1) ensured that transaction isolation level is repeatable_read
2) started shell-1, started a transaction in it, then read a value through select
3) started shell-2, started a transaction in it, then read the same value through select
4) in shell-1, updated the value to value + 1 and committed
5) in shell-2, updated the value to value + 1 and committed
The value lost one of its updates and was incremented only by 1.
Now, as I understand it, RR uses shared read locks and exclusive write locks, which means that in #4 and #5 above, the transactions should have dead-locked, but that did not happen.
So either my understanding of RR is faulty, or MySQL implements RR in a different manner. So what is it?
EDIT: through a similar experiment, also confirmed that an RR transaction (t1) does not see rows inserted into the same table by another RR transaction (t2), if it does another select on that table even after t2 has committed and before t1 committing. (Here's the link to this experiment: http://www.databasejournal.com/features/mysql/article.php/3393161/MySQL-Transactions-Part-II---Transaction-Isolation-Levels.htm)
Does it mean that MySQL's RR takes care of phantom reads also?
回答1:
MySQL does not conform to Repeatable Read really. You can force it to do by using isolation level serializable or by putting an FOR UPDATE after your selects (look at the example below). Then the desired behaviour will be achieved. Regarding phantom reads, MySQL is actually stricter than necessary...
SELECT value FROM table WHERE id = 7 FOR UPDATE;
来源：https://stackoverflow.com/questions/10040785/mysql-repeatable-read-and-lost-update-phantom-reads