content
Control Statements for Common Transactions
ACID characteristics of transactions
Persistence (write log first and then write to disk, efficient)
Transactional concurrency exception
Non-repeatable read (read + read, the result is different)
Phantom reading (read + write, think that you have read it, go to write it, but it does not exist)
Simple knowledge of isolation levels
Transactional understanding
transaction composition
- In simple terms, a transaction can consist of a simple sql statement or a set of complex sql statements ( a transaction is a program logic unit )
Transaction characteristics
- When the database commits a transaction, either all modifications are saved or all modifications are discarded ( atomic, either the entire transaction is completed, or the entire transaction is discarded )
- A transaction is a unit of program execution that accesses and updates various data items in a database
- The innodb engine of mysql supports transactions, myisam does not support transactions , and every sql statement in innodb is a transaction; if we want to cancel the auto-commit transaction, we can set the current session to manually commit the transaction by setting set autocommit = 0;
Control Statements for Common Transactions
-- 显示的开启事务
start transaction | begin;
-- 提交事务，并且对于当前数据库所作的操作修改做持久化
commit;
-- 回滚事务，结束用户的事务，并撤销正在进行的所有未提交的修改
rollback;
-- 创建一个保存点，一个事务可以有多个保存点
savepoint identifier
-- 删除一个保存点
release savepoint identifier
-- 事务回滚到保存点
rollback to [savepoint] identifier
ACID characteristics of transactions
Atomicity (understanding where global data can be written with the help of multi-threading) binding operation unit
- Shallow understanding: This is easy to understand, which means that a transaction must be an atomic operation sequence unit, and all operations can only allow two states in one execution process - either all executions succeed or all executions fail ( bound in a transaction all operations in )
- In-depth understanding: transaction operations are either done (commit) or not done (rollback) ; a transaction is a program execution unit that accesses and updates various data items in the database, and is an inseparable unit of work ; rollback is achieved through undolog operate. The undolog records the specific operation of each step of the transaction. When it is rolled back, the inverse operation of the specific operation of the transaction is played back ; (the principle of rollback is to follow the undolog back to restore the state before the operation)
isolation
- The execution of a transaction cannot be interfered with by other transactions.
- To explain isolation: First understand transaction concurrency. There are many users of our database, and transactions can be executed concurrently. Isolation means that concurrent transactions are isolated from each other and do not interfere with each other . That is to say, when different transactions operate the same data concurrently, each transaction has its own independent and complete data space.
- In -depth understanding of the principle: The isolation of transactions requires that the objects of each read-write transaction can be separated from the operation objects of other transactions , that is, they are not visible to other transactions before the transaction is committed; it is realized through MVCC and locks; MVCC is multi-version concurrent Control , which mainly solves consistent non-locking reads , achieves efficient concurrent read performance by recording and obtaining row versions instead of using locks to limit read operations. Locks are used to handle concurrent DML operations ; the database provides granular locking strategies for three granularity locks: table (clustered index B+ tree), page (clustered index B+ leaf node), and row (a segment of record row in a leaf node).
- MVCC has better performance, avoids adding row lock read operations, and avoids lock waiting
Persistence (write log first and then write to disk, efficient)
- Once the transaction is committed, its changes to the data are persistent. Once the transaction is committed, the related data should change from a free state or a transient state to a persistent state.
- redo log is a log module specific to the InnoDB engine, which records: what changes have been made on a data page;
- When MySQL executes an update statement, the InnoDB engine will first write the record to the redo log file and update the memory. At this point, the update operation is completed, but there is no disk to persist the data update. The InnoDB engine will persist the data update operation to the disk at a suitable time.
- After the transaction is committed, the transaction DML operation will be persistent (which page offset value of the redolog disk file is written to the specific data); even if a failure such as downtime occurs, the database can recover the data. The redo log records the physical log ; ( meaning that all DML operations of the transaction will be written to the redo log disk file, and the location and specific operations of the operation will be recorded in the redo log log, so even if there is a downtime, etc. also recoverable )
Consistency (is a state where data integrity is not destroyed whether it is rolled back or committed)
- It refers to the need to maintain the integrity and consistency of the data before and after the database operation. The execution of the transaction causes the database to be converted from one consistency state to another consistency state , that is to say, before and after the transaction is executed, the integrity constraints of the database are not Destroyed. (eg : Account A transfers 500 yuan to account B, it is impossible to say that account A has decreased by 500 yuan, but account B has not increased by 500 yuan )
- Consistency is maintained by atomicity, isolation, and durability.
Transactional concurrency exception
dirty read
- Transaction A can read data that has not yet been committed by another transaction B. The uncommitted data read by transaction A is the so-called dirty read data . To demonstrate reading dirty read data, first we need to set the isolation level to read uncommitted read uncommitted
- Demonstrate dirty reads
Non-repeatable read (read + read, the result is different)
- Transaction (A) can read the data submitted in another transaction (B); it usually happens that the data read twice in a transaction is not the same; non-repeatable reads exist at the isolation level READ COMMITTED . Generally speaking, the problem of non-repeatable read is acceptable, because reading the submitted data generally does not cause great problems, so the default isolation level of many manufacturers (such as Oracle, SQL Server) is READ COMMITTED
- Transaction A reads for the first time, transaction B has not yet committed, transaction A reads for the second time, transaction B commits, and the results of the two reads will not be consistent
Phantom reading (read + write, think that you have read it, go to write it, but it does not exist)
- A read operation in a transaction cannot support the next business logic; it usually occurs when a read operation in a transaction determines that the next write operation fails ; for example: a table with name as the unique key, query select * from t where name in a transaction = 'mark'; does not exist, then insert into t(name) values ('mark'); an error occurs, and another transaction also performs an insert operation; phantom read exists at isolation level repeatable read and below; but it can be Solved by reading locks (using shared locks) at the repeatable read level ;
- A simple example of phantom reading is that transaction A has just queried a record that does not exist, and then prepares to do an insert operation. At this time, another transaction B inserts the record and submits it. At this time, it is equivalent to the record query just now. illusory, not real, also known as phantom reading
- Solution 1: Add a shared read lock, read lock, and gap lock to the query operation. After locking, other transactions cannot be aligned for insertion operations. When a shared lock is added to the query, transaction B cannot complete the insertion. operation, so as to avoid the phenomenon of phantom reading ( the shared lock in mysql is equivalent to the write lock when we learn the operating system )
- Solution 2: Directly modify the isolation level of the transaction to read sequentially: serializable, the read operation will automatically add the shared lock share in mode after the serialization , but it is basically not recommended, the efficiency is too low, the lock waits, and the performance declines terribly .
Transaction isolation level
-
Simple knowledge of isolation levels
- The higher the transaction isolation level, the safer it will be, but the efficiency will become lower and lower, and the concurrency will become worse and worse
- The default level is generally read committed or repeatable read
- The ISO and ANIS SQL standards have formulated four transaction isolation level standards. Each database manufacturer has made compromises between correctness and performance, and has not strictly followed these standards; the isolation level supported by MySQL innodb by default is REPEATABLE READ ;
-
The underlying implementation of the isolation level (mvcc + various locks) mvcc + various locks are to ensure the isolation, atomicity and other properties between transactions under concurrent execution
- READ UNCOMMITTED read uncommitted; read is not locked at this level, write exclusive lock, write lock is released after transaction commit or rollback ( read uncommitted, read at this level will not be locked, and there is no mvcc )
- READ COMMITTED The read has been committed; the read at this level will not be automatically locked, but mvcc (multi-version concurrency control) is adopted, which is to provide consistent non-locking read, and the read operation reads historical snapshot data at this time; this isolation The latest data of the historical version is read under the level, so the submitted data is read; ( It is precisely because the latest data of the historical version, that is, the currently submitted data, is read, so repeated reading is not supported, because there are other The transaction makes a new submission, and the result of repeated reading of the transaction will be inconsistent with that before the submission )
- REPEATABLE READ Repeatable read; MVCC is also supported at this level, and the read operation reads the version data at the beginning of the transaction
- That is to say, how does repeatable read support repeatable read, no matter how many new versions you submit, I always only read the first version of the open transaction, that is, my first version of historical data, the latest version of historical snapshot data submitted by other transactions I will not pay attention. ( Because I have been reading the first version of the data, naturally it will not cause the problem of repeated data inconsistency due to the latest version of the data. This is reapeatable read, so now I understand why it can support repeated reading of consistent data )
- SERIALIZABLE can be serialized; at this level, a shared lock (S lock) is added to the read; so transactions are executed serially; the isolation level is the most stringent at this time ;
short summary
- First of all, this chapter mainly learns the definition of transactions, understands the important nature of transactions, and initially understands why lock + mvcc supports concurrent multi-transaction execution operations (and understands the underlying implementation of various isolation levels)
- What is a transaction: a simple SQL statement or a collection of multiple complex SQL statements
- What properties do transactions need to guarantee:
- Atomicity: The undo log rollback operation ensures that all SQL statements are either successfully executed or all failed.
- Isolation: mvcc + lock ensures that each transaction of read and write operations is isolated from each other and does not interfere with each other. The write operation must be added with x lock, and the read operation is divided into versions.
- read uncommitted will not lock nor mvcc
- read committed There is mvcc multi-version concurrency control, phantom read may occur, can be avoided by s shared lock, read the latest version of data, there is a non-repeatable read problem,
- Repeatable read reads the oldest version of the data to avoid the problem of repeated data inconsistency, but phantom read may also occur, the solution is to add s shared lock
- serializable: sequential read, automatic s lock for read operation, absolutely safe, but the concurrency is the worst
- Persistence: use redo log to support persistence, modify the physical address of mysql data + how to modify the log record, even if it is down, you can use the redo log log for recovery
- Consistency: Ensure the integrity of the data before and after the transaction, and convert from one consistency state to another consistency state. The consistency guarantee depends on the above three properties
- read committed Read the latest version of the data will have the problem of non-repeatable read ( the data read is the different results before and after the commit of other transactions )
- repeatable read: Repeatable read, read the first version of historical snapshot data, to avoid inconsistent results of repeated read, but there may be a phenomenon of phantom read, phantom read, read + write, and perform update operation according to the read result. Question, just finished reading, other transactions have updated + committed. At this moment, the result of the previous select is already incorrect, and the data read before is the phantom read data ( how to avoid it, plus the s lock )
Leave a post, a detailed explanation of various locks in mysql, locks ----" Transactions are very important