Affairs
Concept: A transaction refers to a set of operations that meet ACID characteristics. A transaction can be submitted through Commit, or it can be rolled back using Rollback.
ACID：
1. Atomicity
The transaction is regarded as the smallest indivisible unit, and all operations of the transaction are either submitted successfully or all failed and rolled back.
Rollback can be achieved by using a rollback log. The rollback log records the modification operations performed by the transaction, and these modification operations can be performed in the reverse direction during rollback.
2. Consistency
The database maintains a consistent state before and after the transaction is executed. In a consistent state, all transactions read the same data.
3. Isolation
Modifications made by one firm are not visible to other transactions until they are finally submitted.
4. Durability
Once the transaction is committed, the changes made will be saved in the database forever. Even if the system crashes, the results of the transaction execution cannot be lost. Use redo logs to ensure durability.
The ACID features of transactions are simple in concept, but they are not well understood, mainly because these features are not a parallel relationship:
- Only when the consistency is met, the execution result of the transaction is correct.
- In the absence of concurrency, transactions are executed serially, and isolation must be satisfied. At this time, as long as the atomicity can be satisfied, the consistency can be satisfied.
- In the case of concurrency, multiple transactions are executed in parallel, and transactions must not only meet atomicity, but also need to meet isolation to meet consistency.
- The transaction satisfies the persistence in order to be able to deal with the situation of the database crash.
AUTOCOMMIT
MySQL uses auto-commit mode by default. In other words, if you do not explicitly use START TRANSACTIONto start a transaction statements, then each query will be treated as a transaction automatically submitted.
Concurrency issues
In a concurrent environment, the isolation of transactions is difficult to guarantee, so there will be many concurrent consistency problems.
Lost changes
Both transactions T1 and T2 modify a piece of data. T1 modifies first, and T2 modifies subsequently. The modification of T2 overwrites the modification of T1.
Read dirty data
T1 modifies a piece of data, and T2 then reads this data. If T1 revokes this modification, the data read by T2 is dirty data.
Non-repeatable
T2 reads a data, and T1 modifies the data. If T2 reads this data again, the result read at this time is different from the result read the first time.
Phantom reading
T1 reads a certain range of data, T2 inserts new data in this range, and T1 reads this range of data again. At this time, the read result is different from the first read result.
The main reason for the concurrency inconsistency problem is that the isolation of the transaction is destroyed, and the solution is to ensure the isolation through concurrency control. Concurrency control can be achieved through blockade, but the blockade operation requires user control, which is quite complicated. The database management system provides a transaction isolation level, allowing users to deal with concurrency and consistency issues in an easier way.
blockade
Blocking granularity
MySQL provides two lock granularities: row-level locks and table-level locks.
You should try to lock only the part of the data that needs to be modified, not all resources. The smaller the amount of locked data, the smaller the possibility of lock contention and the higher the concurrency of the system.
However, locking requires resources, and various lock operations (including acquiring locks, releasing locks, and checking lock status) will increase system overhead. Therefore, the smaller the blocking granularity, the greater the system overhead. When choosing the blocking granularity, there is a trade-off between the lock overhead and the degree of concurrency.
Blocking type
1. Read-write lock
- Exclusive lock (Exclusive), abbreviated as X lock, also known as write lock.
- Shared lock (Shared), abbreviated as S lock, also known as read lock.
There are two regulations:
- A transaction adds X lock to data object A, and then A can be read and updated. During the lock period, other transactions cannot lock A.
- A transaction adds an S lock to data object A, which can perform read operations on A, but cannot perform update operations. During the lock period, other transactions can add S lock to A, but cannot add X lock.
The compatibility of locks is as follows:
2. Intentional lock
Using Intention Locks can more easily support multi-granularity blockade.
In the presence of row-level locks and table-level locks, transaction T wants to add X locks to table A, it needs to check whether other transactions lock table A or any row in table A, then it needs to lock Each row of Table A is checked once, which is very time-consuming.
Intentional locks introduce IX/IS on top of the original X/S locks. IX/IS are table locks, used to indicate that a transaction wants to add an X lock or S lock on a certain data row in the table. There are two regulations:
- Before a transaction obtains the S lock of a certain data row object, it must first obtain the IS lock of the table or a stronger lock;
- Before a transaction can obtain an X lock on a data row object, it must first obtain an IX lock on a table.
By introducing intent locks, transaction T wants to lock table A with X, and only needs to check whether other transactions have added X/IX/S/IS locks to table A. If it is added, it means that other transactions are using this table. Or a row in the table is locked, so transaction T plus X lock fails.
The compatibility of various locks is as follows: The
explanation is as follows:
- Any IS/IX locks are compatible, because they only indicate that they want to lock the table, not the real lock;
- S locks are only compatible with S locks and IS locks. That is to say, transaction T wants to add S locks to the data row, and other transactions can have obtained S locks on the table or rows in the table.
Blockade agreement
1. Three-level lockdown agreement
First-level lockdown agreement
When transaction T wants to modify data A, X lock must be added, and the lock will not be released until T ends. Can solve the problem of lost modification, because two transactions cannot modify the same data at the same time, then the modification of the transaction will not be overwritten.
Secondary lockdown agreement
On the basis of the first level, S lock must be added when reading data A, and the S lock is released immediately after reading.
It can solve the problem of reading dirty data, because if a transaction is modifying data A, according to the level 1 lockout protocol, X locks will be added, then S locks can no longer be added, that is, data will not be read.
Three-level lockdown agreement
On the basis of the second level, S lock must be added when reading data A, and the S lock can not be released until the end of the transaction. It can solve the problem of non-repeatable reading, because when reading A, other transactions cannot add X lock to A, thus avoiding data changes during the reading.
2. Two-stage lock protocol
Locking and unlocking are carried out in two stages.
Serializable scheduling refers to, through concurrency control, that the result of a concurrently executed transaction is the same as the result of a serially executed transaction.
The transaction follows the two-stage lock protocol is a sufficient condition to ensure serializable scheduling. For example, the following operation satisfies the two-stage lock protocol, which is serializable scheduling.
lock-x(A)…lock-s(B)…lock-s©…unlock(A)…unlock©…unlock(B)
But it is not a necessary condition. For example, the following operation does not satisfy the two-stage lock protocol, but it is still serializable.
lock-x(A)…unlock(A)…lock-s(B)…unlock(B)…lock-s©…unlock©
MySQL implicit and explicit locking
MySQL's InnoDB storage engine uses a two-stage lock protocol, which automatically locks when needed according to the isolation level, and all locks are released at the same time, which is called implicit locking.
InnoDB can also use specific statements for display locking:
SELECT … LOCK In SHARE MODE;
SELECT … FOR UPDATE;