Original Address: InnoDB is how to skillfully implement transaction isolation level
Previous article mysql lock mechanism explain , we explain in detail the mechanism innodb lock, the lock mechanism is used to ensure the accuracy of the data in the concurrent circumstances, and to ensure that data is accurate and usually require support services, and storage engine mysql innodb by 4 kinds of lock isolation level mechanism to skillfully implement transaction isolation characteristics in.
Transaction ACID properties, wherein I represents isolation (Isolation). Isolation means that multiple users concurrent transactions accessing the same database, the user's transaction should not interfere with the affairs of other users, to isolation between multiple concurrent transactions.
1. The transaction between how mutual interference
How a transaction is to interfere with other matters it? For example, the following table:
create table lock_example(id smallint(10),name varchar(20),primary key id)engine=innodb;
Data in the following table:
. 1 , zhangsan 2 , Lisi . 3 , wangwu
demo1:
Transaction A, the first execution in the state uncommitted:
insert into t values(4, 'zhaoliu');
Transaction B, after the execution, nor submit:
select * from t;
If the transaction can be read to B (4, zhaoliu) this record, indicating that the transaction A transaction B on an impact, this effect is called " read dirty ", i.e. uncommitted transaction record read operation.
demo2:
Transaction A, the first implementation:
SELECT * from T WHERE ID = . 1 ;
the result set is
1, zhangsan
Transaction B, after the execution, and submit:
update t set name=xxx where id=1;
commit;
Transaction A, the same query again:
select * from t where id=1; The result set as follows: 1, xxx
The impact of the transaction is submitted B on A generates affairs, this effect is called " non-repeatable read ," that the same query within a transaction, but got different results.
demo3:
Transaction A, the first implementation:
select * from t where id>3;
The result set as follows:
NULL
Transaction B, after the execution, and submit:
insert into t values(4, zhaoliu);
commit;
Transaction A, the first query id> Results for NULL, then trying to insert a record 4:
insert into t values(4, xxoo); The result set as follows: Error : duplicate key!
You might be thinking. . . TM you kidding me? Check id> 3 is the empty set, insert id = 4 PK time and told me that conflict? → _ →
The impact of the transaction is submitted B on A generates affairs, this effect is called " phantom read ."
As above, concurrent transactions could lead to other transactions appear read dirty , non-repeatable read , phantom read . In order to avoid the above situation, innodb and what efforts it?
2. InnoDB isolation level achieved what kinds of affairs?
InnoDB implements four different transaction isolation levels:
- Uncommitted Read (Read Uncommitted)
- Read submitted (Read Committed, RC)
- Repeatable Read (Repeated Read, RR)
- Serialization (the Serializable)
Different transaction isolation level is actually consistent with a trade-off and compromise concurrency.
Transaction isolation level 3. The four kinds, innodb how to achieve?
InnoDB uses a different locking strategy (Locking Strategy) to achieve different levels of isolation.
a. Uncommitted Read (Read Uncommitted)
This transaction isolation level, select statement does not lock, nor is a snapshot reading.
SELECT statements are performed in a nonlocking fashion.
At this time, the inconsistent data may be read, i.e., "dirty read." This is the highest concurrency, consistency worst isolation level.
b. reading submitted (Read Committed, RC)
- Ordinary select a snapshot reading;
- Locked select, update, delete statements, etc., in addition to the outer blocking section may key constraint checking (foreign-key constraint checking) and repeating key to check (duplicate-key checking), at other times only use record locking ;
- Lock gap (gap lock), Temporary lock (next-key lock) failure at that level;
In this case, insert other transactions can still execute, it could lead to, to read phantom records. This level is the most commonly used. And if it is not locked select, may produce non-repeatable read.
The next level is a snapshot reading by reading to prevent dirty. Because a snapshot reading at this level can always read the latest snapshot of the data line, of course, it must be committed transactions written, it may produce non-repeatable read.
c. Non Repeatable Read (Repeated Read, RR)
This is the default InnoDB isolation level, under RR:
- Common select read using a snapshot (snapshot read), which is a non-lock of the read consistency (Consistent Nonlocking Read), the bottom layer is achieved using MVCC;
- Locked select (select ... in share mode / select ... for update), update, delete and other statements, their locks, depending on whether they use a single query on a unique index (unique index) ( unique search condition, the use of record locking case), or query range (range-type search condition, this time using the temporary key lock or locks a gap);
- Using unique index only query, uses the locking record (record lock), and the interval between the recording without blocking, i.e. without the use of locking gap (gap lock) and Temporary key lock (next-key lock);
- Range criteria or non-unique indexes, and uses the temporary key lock space lock with index range between the recording, to avoid inter-inserted recording range to avoid ghost rows, and to avoid non-repeatable read;
In this level
- It is achieved by reading the snapshot and a locking section and phantom read to avoid non-repeatable read;
- First read a transaction record of time T, the future will not have time to read the T submitted written record of the transaction after, in order to ensure continuous same read read the same result set, which prevents non-repeatable read;
- RR Phantom read next is to solve the problem through the gap locks, temporary key lock;
d. serializer (the Serializable)
Under this transaction isolation level, all select statements will be implicitly converted to select ... in share mode, which is shared read locks (S locks) on the default.
So, if after the transaction A first execute sql, will try to get the IS lock query row (and other IS, IX locks are compatible), then other transaction can acquire IS lock these lines even lock S but if the next, some rows a transaction if an update or delete them, then you get an X lock, other transactions even perform a normal select statement will be blocked because they are trying to acquire iS lock, but the lock iS and X locks are mutually exclusive, thus avoiding dirty read, non-repeatable read and phantom read, all transactions can only be a serial.
select ... ;
This is the consistency of the best, but the worst isolation level concurrency. High concurrency scene, a little using the d and two isolation levels.
4. Summary
Mutual interference between concurrent transactions, it may cause the transaction to appear dirty read, non-repeatable read, phantom read other issues.
InnoDB implements SQL92 standard four isolation levels:
- Read Uncommitted: select Unlock, may appear dirty read;
- Read Committed (RC): Normal select a snapshot reading, lock select / update / delete will use record locking, non-repeatable read may occur;
- Repeatable Read (RR): Normal select snapshot read, lock select / update / delete query condition according to the situation and the like, selects record locks, or locks the gap / temporary key lock to prevent phantom read record;
- Serialization: select implicitly converted to select ... in share mode, update and delete are mutually exclusive;
InnoDB is the default isolation level RR, the most used isolation level is RC
Original Address: InnoDB is how to skillfully implement transaction isolation level
Previous article mysql lock mechanism explain , we explain in detail the mechanism innodb lock, the lock mechanism is used to ensure the accuracy of the data in the concurrent circumstances, and to ensure that data is accurate and usually require support services, and storage engine mysql innodb by 4 kinds of lock isolation level mechanism to skillfully implement transaction isolation characteristics in.
Transaction ACID properties, wherein I represents isolation (Isolation). Isolation means that multiple users concurrent transactions accessing the same database, the user's transaction should not interfere with the affairs of other users, to isolation between multiple concurrent transactions.
1. The transaction between how mutual interference
How a transaction is to interfere with other matters it? For example, the following table:
create table lock_example(id smallint(10),name varchar(20),primary key id)engine=innodb;
Data in the following table:
. 1 , zhangsan 2 , Lisi . 3 , wangwu
demo1:
Transaction A, the first execution in the state uncommitted:
insert into t values(4, 'zhaoliu');
Transaction B, after the execution, nor submit:
select * from t;
If the transaction can be read to B (4, zhaoliu) this record, indicating that the transaction A transaction B on an impact, this effect is called " read dirty ", i.e. uncommitted transaction record read operation.
demo2:
Transaction A, the first implementation:
SELECT * from T WHERE ID = . 1 ;
the result set is
1, zhangsan
Transaction B, after the execution, and submit:
update t set name=xxx where id=1;
commit;
Transaction A, the same query again:
select * from t where id=1; The result set as follows: 1, xxx
The impact of the transaction is submitted B on A generates affairs, this effect is called " non-repeatable read ," that the same query within a transaction, but got different results.
demo3:
Transaction A, the first implementation:
select * from t where id>3;
The result set as follows:
NULL
Transaction B, after the execution, and submit:
insert into t values(4, zhaoliu);
commit;
Transaction A, the first query id> Results for NULL, then trying to insert a record 4:
insert into t values(4, xxoo); The result set as follows: Error : duplicate key!
You might be thinking. . . TM you kidding me? Check id> 3 is the empty set, insert id = 4 PK time and told me that conflict? → _ →
The impact of the transaction is submitted B on A generates affairs, this effect is called " phantom read ."
As above, concurrent transactions could lead to other transactions appear read dirty , non-repeatable read , phantom read . In order to avoid the above situation, innodb and what efforts it?
2. InnoDB isolation level achieved what kinds of affairs?
InnoDB implements four different transaction isolation levels:
- Uncommitted Read (Read Uncommitted)
- Read submitted (Read Committed, RC)
- Repeatable Read (Repeated Read, RR)
- Serialization (the Serializable)
Different transaction isolation level is actually consistent with a trade-off and compromise concurrency.
Transaction isolation level 3. The four kinds, innodb how to achieve?
InnoDB uses a different locking strategy (Locking Strategy) to achieve different levels of isolation.
a. Uncommitted Read (Read Uncommitted)
This transaction isolation level, select statement does not lock, nor is a snapshot reading.
SELECT statements are performed in a nonlocking fashion.
At this time, the inconsistent data may be read, i.e., "dirty read." This is the highest concurrency, consistency worst isolation level.
b. reading submitted (Read Committed, RC)
- Ordinary select a snapshot reading;
- Locked select, update, delete statements, etc., in addition to the outer blocking section may key constraint checking (foreign-key constraint checking) and repeating key to check (duplicate-key checking), at other times only use record locking ;
- Lock gap (gap lock), Temporary lock (next-key lock) failure at that level;
In this case, insert other transactions can still execute, it could lead to, to read phantom records. This level is the most commonly used. And if it is not locked select, may produce non-repeatable read.
The next level is a snapshot reading by reading to prevent dirty. Because a snapshot reading at this level can always read the latest snapshot of the data line, of course, it must be committed transactions written, it may produce non-repeatable read.
c. Non Repeatable Read (Repeated Read, RR)
This is the default InnoDB isolation level, under RR:
- Common select read using a snapshot (snapshot read), which is a non-lock of the read consistency (Consistent Nonlocking Read), the bottom layer is achieved using MVCC;
- Locked select (select ... in share mode / select ... for update), update, delete and other statements, their locks, depending on whether they use a single query on a unique index (unique index) ( unique search condition, the use of record locking case), or query range (range-type search condition, this time using the temporary key lock or locks a gap);
- Using unique index only query, uses the locking record (record lock), and the interval between the recording without blocking, i.e. without the use of locking gap (gap lock) and Temporary key lock (next-key lock);
- Range criteria or non-unique indexes, and uses the temporary key lock space lock with index range between the recording, to avoid inter-inserted recording range to avoid ghost rows, and to avoid non-repeatable read;
In this level
- It is achieved by reading the snapshot and a locking section and phantom read to avoid non-repeatable read;
- First read a transaction record of time T, the future will not have time to read the T submitted written record of the transaction after, in order to ensure continuous same read read the same result set, which prevents non-repeatable read;
- RR Phantom read next is to solve the problem through the gap locks, temporary key lock;
d. serializer (the Serializable)
Under this transaction isolation level, all select statements will be implicitly converted to select ... in share mode, which is shared read locks (S locks) on the default.
So, if after the transaction A first execute sql, will try to get the IS lock query row (and other IS, IX locks are compatible), then other transaction can acquire IS lock these lines even lock S but if the next, some rows a transaction if an update or delete them, then you get an X lock, other transactions even perform a normal select statement will be blocked because they are trying to acquire iS lock, but the lock iS and X locks are mutually exclusive, thus avoiding dirty read, non-repeatable read and phantom read, all transactions can only be a serial.
select ... ;
This is the consistency of the best, but the worst isolation level concurrency. High concurrency scene, a little using the d and two isolation levels.
4. Summary
Mutual interference between concurrent transactions, it may cause the transaction to appear dirty read, non-repeatable read, phantom read other issues.
InnoDB implements SQL92 standard four isolation levels:
- Read Uncommitted: select Unlock, may appear dirty read;
- Read Committed (RC): Normal select a snapshot reading, lock select / update / delete will use record locking, non-repeatable read may occur;
- Repeatable Read (RR): Normal select snapshot read, lock select / update / delete query condition according to the situation and the like, selects record locks, or locks the gap / temporary key lock to prevent phantom read record;
- Serialization: select implicitly converted to select ... in share mode, update and delete are mutually exclusive;
InnoDB is the default isolation level RR, the most used isolation level is RC