Article directory
interview questions
1. What are the problems caused by parallel transactions?
2. What are the characteristics of transactions?
3. How are the principles of transactions/characteristics of transactions realized?
4. What are the isolation levels of transactions?
affairs
1. Concept
Database transaction (Transaction) is a mechanism, a sequence of operations, includingA set of database operation commands。
The transaction submits or revokes the operation request to the system together with all commands as a whole, that is, this group of database commandsEither both succeed or both fail。
A transaction is an indivisible logical unit of work.
grammar:
| operate | meaning |
|---|---|
| open transaction | START TRANSACTION or BEGIN ; |
| commit transaction | COMMIT; |
| rollback transaction | ROLLBACK |
The default MySQL transaction is automatically committed. When a DML statement is executed , MySQL will immediately and implicitly commit the transaction. (When executing the above open transaction statement, you need to manually submit the transaction)
2. The four major characteristics of transactions ACID
-
Atomicity : A transaction is an indivisible minimum unit of operation that either succeeds or fails at the same time
-
Consistency : When the transaction is completed, all data must be kept in a consistent state (for example, in the transfer problem, the total amount of money before the transaction is opened and the total amount of money after the opening must be consistent)
-
Isolation : (due to the ability of the database to allow multiple concurrent transactions to read, write and modify its data at the same time ), the isolation mechanism provided by the database system ensures that transactions run in an independent environment that is not affected by external concurrent operations.
-
Durability : Once a transaction is committed or rolled back, its changes to the data in the database are permanent
3. Operation
The most classic example is the transfer problem. If Zhang San and Li Si's accounts each have 1,000 yuan, and now Li Si transfers 500 to Zhang San's account, then Zhang San's account should be 1500 after the transfer is successful, and Li Si's account is 500.
However, if the transaction is not opened and an exception occurs during the entire operation, it will cause Li Si's transfer operation to succeed, but Zhang San's account addition operation fails .
Understanding from the code point of view:
(1) First, the normal situation
-- 1. 查询张三余额
select * from account where name = '张三';
-- 2. 张三的余额减少1000
update account set money = money - 1000 where name = '张三';
-- 3. 李四的余额增加1000
update account set money = money + 1000 where name = '李四';
(2) Abnormal situation (abnormal situation occurs during the transfer)
-- 1. 查询张三余额
select * from account where name = '张三';
-- 2. 张三的余额减少1000
update account set money = money - 1000 where name = '张三';
出错了....
-- 3. 李四的余额增加1000
update account set money = money + 1000 where name = '李四';
At this time, the third statement was not executed because of the exception of the previous "error...", so the final result was unsuccessful.
(3) So use the transaction
-- 开启事务
start transaction
-- 1. 查询张三余额
select * from account where name = '张三';
-- 2. 张三的余额减少1000
update account set money = money - 1000 where name = '张三';
-- 3. 李四的余额增加1000
update account set money = money + 1000 where name = '李四';
-- 如果正常执行完毕, 则提交事务
commit;
-- 如果执行过程中报错, 则回滚事务
-- rollback;
When an exception occurs, it can be recovered after rolling back the transaction, as shown in the following figure:
concurrent transaction problem
The MySQL server allows multiple clients to connect, which means that MySQL will process multiple transactions at the same time. There are also a series of problems.
1. Dirty read
A transaction reads data that has not been committed by another transaction.
Explanation:
A transaction reads data and modifies the data, which is visible to other transactions even if the current transaction is not committed. At this time, another transaction reads the uncommitted data, but the first transaction suddenly rolls back, resulting in the data not being submitted to the database, and the second transaction reads dirty data
For example: transaction 1A reads the data A=20 in a certain table, transaction 1 modifies A=A-1, transaction 2 reads A=19, transaction 1 rolls back and causes the modification of A to be submitted to the database, A’s The value is still 20.
2. Non-repeatable read
A transaction reads the same record successively, but the data read twice is different, which is called non-repeatable read.
A transaction reads the same record successively, but the data read twice is different. Transaction 2 reads the same record twice, but the data read is different
3. Phantom reading
When a transaction queries data according to conditions, there is no corresponding data row, but when inserting data, it is found that this row of data already exists, as if there is a "phantom".
So how to solve these concurrent transactions, leading to the following transaction isolation level
Transaction isolation level (to solve concurrency problems)
There are mainly the following four isolation levels: read uncommitted, read committed, repeatable read, and serializable. The
default supported isolation level of the MySQL InnoDB storage engine is REPEATABLE-READ (rereadable) (that is, it can avoid dirty reads) and non-repeatable read)
Note: The higher the transaction isolation level, the more secure the data, but the lower the performance.
grammar:
| operate | meaning |
|---|---|
| SELECT @@TRANSACTION_ISOLATION; | View transaction isolation level |
| SET [ SESSION | GLOBAL ] TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE } | Set transaction isolation level |
Principle of business
So what technology does the InnoDB engine use to ensure these four characteristics of transactions?
Persistence is guaranteed by redo log (redo log);
atomicity is guaranteed by undo log (rollback log);
isolation is guaranteed by MVCC (multi-version concurrency control) + lock mechanism;
consistency It is guaranteed by persistence + atomicity + isolation;
1.redo log (redo log)
The redo log, which records the physical modification of the data page when the transaction is committed, is used to achieve the persistence of the transaction.
The log file consists of two parts: redo log buffer (redo log buffer) and redo log file (redo log file), the former is in memory, the latter is in disk. After the transaction is committed, all modification information will be stored in the log file, which is used for data recovery when dirty pages are flushed to disk and errors occur.
2.undo log (rollback log)
The rollback log is used to record the information before the data is modified. It has two functions: providing rollback (guaranteeing the atomicity of transactions) and MVCC (multi-version concurrency control).
Undo log and redo log record physical log is not the same, it is a logical log. It can be considered that when a record is deleted, a corresponding insert record will be recorded in the undo log, and vice versa, when a record is updated, it will record a corresponding update record. When the rollback is executed, the corresponding content can be read from the logical records in the undo log and rolled back
3. MVCC (multi-version concurrency control)
Multiple versions of a data are maintained so that read and write operations do not conflict. Lock-free concurrency control to resolve read-write conflicts
(1) Basic concepts
The current read
reads the latest version of the record . When reading, it must be ensured that other concurrent transactions cannot modify the current record, and the read record will be locked. For our daily operations, such as: select ... lock in share mode (shared lock), select ... for update, update, insert, delete (exclusive lock) are all current reads.
Snapshot read
Simple select (without lock) is snapshot read, snapshot read, reads the visible version of recorded data, possibly historical data, without lock, is non-blocking read.
(2) Hidden fields
(3) undo log version chain
Modifying the same record by different transactions or the same transaction will cause the undolog of the record to generate a
record version linked list. The head of the linked list is the latest old record, and the tail of the linked list is the earliest old record.
(4) ReadView
ReadView (read view) is the basis for MVCC to extract data when snapshot read SQL is executed, and records and maintains the currently active transaction (uncommitted) id of the system.
Contains four core fields:
In readview, the access rules of the version chain data are stipulated: trx_id represents the transaction ID corresponding to the current undolog version chain.
(5) Implementation principle
Different isolation levels have different timings for generating ReadView:
- READ COMMITTED : A ReadView is generated every time a snapshot read is performed in a transaction.
- REPEATABLE READ: ReadView is only generated when the snapshot read is executed for the first time in the transaction, and the ReadView is reused later (so the result returned by the final snapshot read is also the same.)
Reference link: https://javaguide.cn/database/
https://www.bilibili.com/video/BV1Kr4y1i7ru?p=145&vd_source=752a4cd440b20a1953dc8d254ef99696