Among MySQL's many storage engines, only InnoDB supports transactions. All the transaction isolation levels mentioned here refer to the transaction isolation level under InnoDB.
Read uncommitted: One transaction can read the uncommitted modifications of another transaction. This will cause dirty reads, phantom reads, and non-repeatable reads. (Basically useless)
Read committed: A transaction can only read the modifications that have been committed by another transaction. It avoids dirty reads, but still has the problem of non-repeatable reads and phantom reads.
Repeatable read: Read the same data multiple times in the same transaction and return the same result. It avoids the problems of dirty reads and non-repeatable reads, but phantom reads still exist.
Serialization: Transactions are executed serially. Avoid all the above problems.
The above are the four isolation levels defined in the SQL-92 standard. In MySQL, the default isolation level is REPEATABLE-READ (repeatable read), and it solves the problem of phantom reading. Simply put, the default isolation level of mysql solves the problems of dirty reads, phantom reads, and non-repeatable reads.
Non-repeatable reading focuses on update and delete, while phantom reading focuses on insert.
Basic transaction data (ACID)
1 Atomicity (ATOMICITY)
At the beginning of the transaction, all operations are either done or not done. It is impossible to stay in the middle link. Errors during the execution of the transaction must be rolled back to the state before the transaction started.
2 Consistency (CONSISTENCY)
Before and after the transaction started, the integrity constraints of the database were not destroyed. For example, it is impossible for A to transfer money to B. A deducted the money, but B did not receive it.
3 Isolation (ISOLATION)
At the same time, only one transaction is allowed to request the same data, and there is no interference between different transactions.
4 Durability (DURABILITY)
Transaction concurrency brings isolation problems
1 Dirty read: Transaction A reads the data being updated by transaction B, and then B rolls back the operation, then the data read by transaction A is dirty.
2 Non-repeatable: Transaction A reads the same batch of data multiple times, and Transaction B updates and commits the data during the multiple reads of Transaction A. The data read before and after transaction A is inconsistent.
3 Phantom read: Transaction A modifies the data, transaction B inserts a conditional data, and when transaction A reads it again, it is found that there is still a piece of data that has not been modified.
Transaction is composed of 1 statement and multiple statements
Transaction -> multiple statements (SELECT UPDATE INSERT DELETE) --> each statement locks 1 or more records
MYSQL isolation level
Read uncommitted (RU) can be dirty read, phantom read, non-repeatable read
Read submitted (RC) not allowed, phantom read, not repeatable
Repeatable read (RR) No, phantom read, repeatable
Serialization (SR) is impossible
ORACLE is to read submitted MYSQL. The default is RR level repeatable read, and gap lock is used to solve phantom reads.
In a distributed database, how can transactions solve the above-mentioned transaction concurrency problem?
Suppose there are two sharded tables, T_USER and T_ACCOUNT use USERID and ACCOUNT_ID as HASH shards respectively
Suppose we have 4 shard databases, which are called 4 data nodes according to MYCAT.
For example, single statement transaction UPDATE T_USER SET AGE=38 WHERE USER_NAME LIKE'Old King%'
For example, multi-statement transactions
BEGIN
UDPATE T_ACCOUNT SET MONEY-50 WHERE USER_NAME='老王'
UPDATE T_ACCOUNT SET MONEY+50 WHERE USER_NAME='Lao Wang's wife'
commit;
END;
MVCC
There are two hidden fields in each row: create transaction number and delete transaction number
SELECT: First query will get a transaction number, we call it the query transaction number
Then it will compare (create transaction number <= query transaction number) AND (delete transaction number=NULL OR delete transaction number> query transaction number)
INSERT saves its own transaction number in the creation transaction number
UPDATE: First insert a row to save your own transaction number in the creation transaction number, and then replace the original row delete transaction number with your own transaction number
DELETE: save your own transaction number in the delete transaction number
Snapshot read and current read
Snapshot read is to read historical version, current read is to read the latest version, SELECT is snapshot read. UPDATE, DELETE INSERT, SELECT LOCK IN SHARE MODE, SELECT FOR UPDATE currently read.
Locked read and consistent non-locked read
In a transaction, the SELECT statement does not lock, unless SELECT LOCK IN SHARE MODE and SELECT FOR UDPATE
SELECT LOCK IN SHARE MODE adds a shared lock SR to the record, and other transactions are read-only and cannot be modified until the transaction is committed.
SELECT FOR UDPATE adds an exclusive lock to the record, and other RX transactions can only be read by snapshot but not currently.
Consistent non-locking read
It is for the consistency of the read data and does not lock the record at the same time.
If it is under the RR isolation level: then all consistent reads in the same transaction are the first such reads in the transaction to read the snapshot;
If in the RC isolation level: then every consistent read in a transaction will read its own new snapshot version
Common SELECT under RR and RC is consistent read
MYSQL lock
RECORD LOCKS record lock lock on the record
GAP LOCKS locks between records, or locks before the first record, and locks after the last record
NEXTKES Next keyword lock: GAP+RECORD LOCKS
index
KEY+RECORDS
10, 11, 13, 20 Then the NEXT-KEY lock of this index will cover the interval
(NEGATIVE INFINITY,10) negative infinity
(10,11]
(11,13]
(13,20]
(20,POSITIVE INFINITY) positive infinity
Under the default isolation level, RR uses consistent reads without locking for ordinary SELECTs
UPDATE DELETE needs to be locked, as to which lock to add depends on the situation
1 The use of a unique index as a search condition requires a record lock
2 No unique index is used, or GAP or NEXTKEY lock is used for index range scan
This should include a unique index range scan
According to the addition, deletion, checking and modification under MVCC, there will be no problems, phantom reading and repeated reading.
But it is wrong because the transaction using snapshot read will cause data loss.
So DML transaction statements use current reads, while SELECT uses snapshot reads.
MVCC consistent reading ensures repeatable reading
Gap lock guarantees no phantom reading
ORACLE supports two isolation levels RC SR no RR
SET TRANSACTION ISOLATION LEVEL READ COMMITTED|SERIALIZABLE
You can avoid phantom reads by setting the transaction level SR instead of implementing locks. The data read by SR is the data before the time the transaction started
This requires MVCC to support