Repeatable read in the same transaction, when the same query is made multiple times, a different result set is returned each time due to a transaction commit of another insert operation (insert).
The standard repeatable read allows for Phantom reads, because this level only adds a shared lock on the read record, preventing other transactions from being modified, but does not prohibit others from inserting new data.
When they first read, they are cured (snapshots), they can no longer find their own changes, but it does not prohibit others to modify the delete insert.
What does this level fit to do? In fact, it is not suitable for the general online trading similar, but more suitable for statistical query report class requirements.
For example, we need to base some detail, statistics, and save the results in a few other tables, that is, unable to complete with a SQL, using MySQL RR is more appropriate
Begn work
INSERT INTO TJ1 select * from t where ....
INSERT INTO TJ2 select * from t where ....
Commit
If you use the Read commit level and tj1 is inserted, t may be modified to add new deletions, then the tj2 result may not be consistent with the underlying data of tj1.
However, there is no problem with RR levels. So the first reading was cured. Even if T is emptied later, it does not affect the results of tj2.
MySQL different transaction isolation levels