First, create a table account. The process of creating a table skip (because the InnoDB storage engine supports transactions, so the table storage engine is set to InnoDB) . Configuration table is as follows:
Then insert data into two tables, after inserting the following results:
To illustrate the problem, we are open two consoles to log in to simulate two users (for the time being as a user A and user B, right), and set the transaction isolation level of the current MySQL session.
A. Read uncommitted (read uncommitted)
Specific user A operated as follows:
set session transaction isolation level read uncommitted； start transaction; select * from account;
The results are as follows:
User B's operation as follows:
set session transaction isolation level read uncommitted; start transaction; update account set account=account+ 200 where id = 1 ;
Then we query data in A user with the following results:
A conclusion
We'll transaction isolation level to read uncommitted, even if the transaction did not commit, but we can still read the uncommitted data, which is the lowest level of all kind of isolation
So do you have any questions?
That we can casually read the data in a transaction other uncommitted transaction, which is quite troublesome, we called dirty read . I do not know how the name is played, in order to enhance the impression that we can think, this transaction is good frivolous ah, hungry to even things that nobody else has submitted can not wait, really dirty, bah!
In fact, our data changed?
The answer is no , inside the database data has not changed , because the database will be updated only after the transaction commit.
Two. Read committed (to read data from other transactions submitted) --- Most database default isolation level
The same way, we will be a session where the user B's current transaction isolation level to read commited. A user session where we perform the following operations:
Update Account Account-SET 200 is Account WHERE ID = =. 1;
We will account id = user 1 by 200. Then inquiry found id = 1 user account becomes 800.
B in the session where the user query:
-
select * from account；
The results are as follows:
We find that the data has not changed, or 1000.
Then we will submit the transaction in session A:
commit;
In session B, the query results are as follows:
Conclusion 2:
When we set the isolation level is read committed the current session, the current session only read data to other transactions submitted not read uncommitted data.
So do you have any questions?
That is what we in the session B the same transaction, read two different results. This has resulted in non-repeatable read, it is the result of two different read. This phenomenon is called non-repeatable read.
Three. Repeatable read (can be re-read) --- MySQL default isolation level
Now there is a demand, that is, the boss said queries in the same transaction results must be consistent, if you are a database, how would you do? The database is doing.
We are currently in session B transaction isolation level is repeatable read. Specific operation is as follows:
set session transaction isolation level repeatable read; start transaction;
Then query data in session B:
We account for the table to add a data session A user is located in:
insert into account(id,account) value( 3 , 1000 ); commit;
Then we look at the data insertion query is successful:
Back to the session where the user B, we query results:
User B wants to insert a new data session id = 3 where he's, value = 1000. We operate under to:
what? Actually could not get into, I say duplication of data?
User B, of course not satisfied with, ah, because the query to the data only two ah, why insert id = 3 data that I repeat it?
I see it again, does my vertigo?
Just look at the actual user A and user B must be isolated from each other, we do not know what to do with each other. User B encountered this phenomenon, certainly fried hair ah, obviously the absence of data, say the primary key is inserted into the data repeat id = 3.
Conclusion three:
When we current session isolation level is set to repeatable read, the current session can be repeated read, read each time the result set is the same, regardless of other matters have not been submitted.
Any questions?
Who cares, the boss of the requirements to meet. Consistent with the data to a read transaction (repeatable read). I can only do that, ah, swollen face loaded fat. Data has changed, but I still have to be consistent. However, there is a problem faced by the user B, a phenomenon called phantom read (remember tangle for a long time in this place, in the end what is the magic reading ah).
Four. Serializable (serialization)
Similarly, we will transaction isolation level for a session where the user B is set to serializable and turn affairs.
set session transaction isolation level serializable; start transaction;
In the session where the user B, we perform the following operations:
select * from account;
The results are as follows:
Then we write data to it this time in a session where the user A's?
We found A session where the user goes into a wait, if the timeout (this time can be configured), there will Lock wait time out tips:
If the session transaction while waiting for our users submit B is located, then writes the transaction where the user will be prompted A successful operation.
Conclusion Four:
When we current session isolation level to serializable when other sessions write to the table will be suspended. You can see, this is the most stringent isolation level, but doing so will inevitably impact on performance. So the actual selection, we want the current specific situation appropriate choice.