Table of contents
In MySQL, transaction support is implemented at the engine layer . MySQL is a system that supports multiple engines, but not all engines support transactions. For example, MySQL's native MyISAM engine does not support transactions , which is one of the important reasons why MyISAM was replaced by InnoDB.
Isolation and isolation levels
ACID (Atomicity, Consistency, Isolation , Durability, that is, atomicity, consistency, isolation , and durability).
When multiple transactions are executed simultaneously on the database , problems such as dirty read , non -repeatable read , and phantom read may occur . In order to solve these problems, there is " The concept of "isolation level ".
The higher the isolation level, the less efficient it will be. Therefore, it is often necessary to find a balance between the two. SQL standard transaction isolation levels include: read uncommitted (read uncommitted), read committed (read committed), repeatable read (repeatable read) and serializable (serializable) .
- Read uncommitted means that before a transaction is committed, the changes it makes can be seen by other transactions.
- Read commit means that after a transaction is committed, the changes it makes will be seen by other transactions.
- Repeatable reading means that the data seen during the execution of a transaction is always consistent with the data seen when the transaction is started. Of course, under the repeatable read isolation level, uncommitted changes are also invisible to other transactions. (Applicable to cases of month-end data proofreading logic)
- Serialization , as the name suggests, means that for the same row of records, "write" will add a "write lock", and "read" will add a "read lock". When a read-write lock conflict occurs, the transaction accessed later must wait for the completion of the previous transaction before it can continue to execute.
Under different isolation levels, what are the different return results of transaction A in the following example, that is, what are the return values of V1, V2, and V3 in the table.
- If the isolation level is " read uncommitted ", the value of V1 is 2. At this time, although transaction B has not yet been submitted, the result has been seen by A. Therefore, V2 and V3 are both 2.
- If the isolation level is " read committed ", then V1 is 1 and the value of V2 is 2. The updates of transaction B can only be seen by transaction A after they are committed. Therefore, the value of V3 is also 2.
- If the isolation level is " repeatable read ", then V1 and V2 are 1, and V3 is 2. The reason why V2 is still 1 is to follow this requirement: the data seen before and after the transaction is executed must be consistent.
- If the isolation level is " serialization ", transaction B will be locked when it executes "change 1 to 2". Transaction B cannot continue execution until transaction A commits. So from A's perspective, the values of V1 and V2 are 1, and the value of V3 is 2.
| Transaction A | Transaction B |
|---|---|
| Start the transaction and query to get the value 1 | Start transaction |
| The query gets the value 1 | |
| Change 1 to 2 | |
| Query to get the value V1 | |
| Commit transaction B | |
| Query to get the value V2 | |
| Commit transaction A | |
| Query to get the value V3 |
In terms of implementation, a view will be created in the database , and the logical result of the view will prevail when accessing. Under the " repeatable read " isolation level, this view is created when the transaction starts and is used throughout the transaction. Under the " read committed " isolation level, this view is created at the beginning of each SQL statement . What needs to be noted here is that under the " read uncommitted " isolation level , the latest value on the record is directly returned, without the concept of a view ; while under the " serialization " isolation level , locking is directly used to avoid parallel access.
The default isolation level of the Oracle database is actually " read commit ". Therefore, for some applications that are migrated from Oracle to MySQL, in order to ensure the consistency of the database isolation level, you must remember to set the isolation level of MySQL to "read commit " .
The configuration method is to transaction-isolationset the value of the startup parameter to READ-COMMITTED. Can be mysql> show variables like 'transaction_isolation';used to view the current value.
Implementation of transaction isolation
In MySQL, each record actually records a rollback operation when it is updated . The latest value on the record can be obtained by rolling back the value of the previous state. Suppose a value is changed from 1 to 2, 3, and 4 in order, there will be a record similar to the following in the rollback log. The current value is 4, but when querying this record, the transactions started at different times will be different . As you can see in the figure, in views A, B, and C, the values of this record are 1, 2, and 4 respectively. The same record can have multiple versions in the system, which is the multi-version concurrency control of the database ( ) . For , to get 1, the current value must be obtained by executing all the rollback operations in the figure.
read-viewMVCCread-view A
The system will judge that when there is no earlier rollback log in the system read-view, the rollback log will be deleted.
Try not to use long transactions : Long transactions mean that there will be very old transaction views in the system . Since these transactions may access any data in the database at any time, all rollback records that may be used in the database must be retained before the transaction is committed, which will occupy a large amount of storage space. In MySQL 5.5 and previous versions, the rollback log is placed in the file together with the data dictionary . Even if the long transaction is finally committed and the rollback segment is cleared, the file will not become smaller. ibdataFor example, the data is only 20GB, and the rollback segment has a 200GB library. In the end, I had to rebuild the entire library in order to clean up the rollback segment. In addition to the impact on rollback segments, long transactions also occupy lock resources and may bring down the entire library.
How a transaction is started
- Explicitly start the transaction statement, begin or start transaction. The matching commit statement is commit and the rollback statement is rollback.
- set autocommit=0, this command will turn off automatic submission of this thread. This means that if you only execute a select statement, the transaction will be started and will not be automatically committed. This transaction continues to exist until you actively execute a commit or rollback statement, or disconnect
- When autocommit is 1, a transaction started explicitly with begin will be committed if commit is executed. If you execute commit work and chain, the transaction is committed and the next transaction is automatically started , which also saves the overhead of executing the begin statement again.
-- 在information_schema库的innodb_trx表中查询长事务，用于查找持续时间超过60s的事务
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60
MySQL transaction code example
-- mysql 自动开启事务提交
SET autocommit=0 -- 关闭
SET autocommit=1 -- 开启（默认的）
-- 手动处理事务
SET autocommit =0 -- 关闭自动提交
-- 事务开启
START TRANSACTION -- 标记一个事务的开始，从这个之后的SQL都在同一个事务内
INSERT XX
INSERT XX
-- 提交 ： 持久化(成功)
COMMIT
-- 回滚： 回到原来的样子（失败）
ROLLBACK
-- 事务结束
SET autocommit = 1 -- 开启自动提交
-- 了解
SAVEPOINT 保存点名称 -- 设置一个事务的保存点
ROLLBACK TO SAVEPOINT 保存点名 -- 回滚到保存点
RELEASE SAVEPOINT 保存点 -- 删除保存点