Article directory
4.5, MySQL transaction control
Basic Operations of Transactions
rollback transaction to savepoint
Concurrent processing of transactions
foreword
This article talks about the knowledge about MySQL transaction control. I wish you a happy Qingming Festival tomorrow! In addition, the friends who have passed by will like and follow before walking, welcome to communicate in the comment area, and work hard to grow together!
refill
4.5 , MySQL transaction control
business concept
Transactions are supported in MySQL only for databases or tables that use the Innodb database engine.
A transaction is the smallest logical unit of work consisting of a series of related SQL statements. For each operation in the transaction either all completes or none of them are performed. (For example: Bank transfer is a two-step transaction, one account is reduced in funds and another is increased in funds. The total amount of property should be the same. So you can't just perform any one of them)
Four characteristics of ACID
Atomicity: Transactions are atomic, and all SQL statements contained in a transaction form an indivisible unit of work, either all SQL statements are completed or not.
Consistency: The result of transaction execution must be to transition the database from one consistent state to another, with no intermediate states (the integrity of the database is not destroyed).
Isolation (lsolation): The execution of a transaction in the database is not interfered by other transactions, and each transaction does not feel that there are other transactions executing concurrently. It prevents data inconsistency caused by cross execution when multiple transactions are executed concurrently.
Durability: Once a transaction is committed, the changes to the data in the database are permanent, and subsequent operations or failures will not have any impact on the operation results of the transaction.
Classification of affairs
Transactions can be divided into the following two categories according to the way they are defined:
Auto-commit transactions
MySQL runs in this mode by default. When a statement that modifies table data is executed, even if there is no user-defined transaction, MySQL will immediately store the result to disk, which is called an auto-commit transaction. Each MySQL statement is committed or rolled back when it completes. If a statement completes successfully, the statement is committed; if an error is encountered, the operation of the statement is rolled back.
explicit transaction
Refers to a transaction that explicitly defines the start (start transaction | begin work) and end (commit or rollback work). In practical applications, most transactions are defined by the user. The end of a transaction is divided into two states: commit and rollback. The transaction ends with a commit state, committing the result of the operation to the database. If the transaction ends in a rollback state, all operations of the transaction are canceled, and the transaction operation fails.
Basic Operations of Transactions
In the previous article, it was also mentioned in the foundation of the database that there are four basic operations of transaction control, namely, opening a transaction, committing a transaction, rolling back a transaction, and saving a restore point. The following are related descriptions and transaction control statements.
Turn off autocommit
The default value of the MySQL system variable @@autocommit is 1, and the autocommit function is enabled by default. The transaction ends when a statement is automatically committed. So in order to be able to operate a transaction consisting of multiple SQL statements. User must turn off auto-commit.
There are two ways to turn off autocommit:
1. Execute the following statement. After execution, the termination of each transaction must be clearly indicated, and the modification made to the database by the SQL statement in the transaction can become a persistent modification.
set @@autocommit=0;
2. Use the MySQL command "start transaction;" or "begin;" to implicitly turn off automatic prompts.
pay. Implicitly turning off autocommit does not modify the value of the system session variable @@autocommit.
start transaction
START TRANSACTION;
or BEGIN;
transaction commit
COMMIT;
Note: MySQL does not allow nested transactions. After using the start transaction command in the first transaction, the first transaction is automatically committed when the second transaction starts. A commit command is executed when the following MySQL statements are run: drop database / drop table /create index/ drop index/alter table /rename table /lock tables / unlock tables /set @@autocommit=1
transaction rollback
Rollback ends the user's transaction and undoes any uncommitted modifications in progress.
ROLLBACK;
or ROLLBACK WORK;
set savepoint
To roll back the transaction to a certain point, implement a partial rollback of the transaction. Allows to create a savepoint in a transaction, and there can be multiple SAVEPOINTs in a transaction;
SAVEPOINT savepoint name;
Delete a savepoint of a transaction. When no savepoint is specified, executing the statement will throw an exception;
RELEASE SAVEPOINT savepoint name;
rollback transaction to savepoint
ROLLBACK TO SAVEPOINT savepoint name;
Note: If the current transaction makes changes to the data after the savepoint is set, those changes will be rolled back during the rollback process. When a transaction is rolled back to a savepoint, savepoints set after that savepoint are deleted.
Example:
transaction rollback
START TRANSACTION;
INSERT INTO department VALUES(70,'name70','loc70');
INSERT INTO department VALUES(80,'name80','loc80');
ROLLBACK;
SELECT*FROM department;
transaction savepoint commit rollback transaction
START TRANSACTION;
INSERT INTO department VALUES(70,'name70','loc70');
SAVEPOINT sp1;
INSERT INTO department VALUES(80,'name80','loc80');
UPDATE department SET loc='loccc'WHERE deptno=70;
ROLLBACK TO sp1;
SELECT *FROM department;
Concurrent processing of transactions
MySQL supports multiple users sharing the same database, but when multiple users operate the same data at the same time, certain concurrency problems will occur.
Transactions can ensure data integrity and consistency. However, when multiple transactions in the same database operate the same data concurrently, data inconsistency may occur.
There are four main types of database inconsistencies caused by concurrent operations of the database:
lost update
Refers to when two or more transactions select the same row and then update the row based on the initially selected value, since each transaction is unaware of the existence of the other transactions, the last update will overwrite the updates made by the other transactions, resulting in data loss.
dirty read
Refers to a transaction is accessing data, and other transactions are updating the data, but not yet committed, the data read by the first transaction is "dirty" (incorrect) data. The dirty read problem violates the isolation principle of transactions.
non-repeatable read
Refers to two identical query statements in the same transaction, and the query results are inconsistent. That is, when a transaction accesses the same row multiple times and reads different data each time, there will be a non-repeatable read problem. Because other transactions may be updating data that this transaction is reading.
hallucinations
A phantom read problem occurs when an insert or delete operation is performed on a row that falls within the scope of the row that a transaction is reading. Rows that existed when a transaction first read a row range no longer exist on subsequent reads due to delete operations by other transactions. Similarly, due to inserts by other transactions, subsequent reads show rows that did not exist at the time of the original read.
transaction isolation level
SET TRANSACTION is used to set the isolation level of the transaction. The InnoDB storage engine provides transaction isolation levels with READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, and SERIALIZABLE. The following four isolation levels are gradually increased.
READ UNCOMMITTED:
All transactions can see the execution results of other uncommitted transactions, it is rarely used in practical applications, and its performance is not much better than other isolation levels.
READ COMMITTED:
This is the default isolation level for most database systems (but not the MySQL default). It satisfies the simple definition of isolation, that a transaction can only see changes made by committed transactions.
REPEATABLE READ:
MySQL's default transaction isolation level, which ensures consistent execution results of the same query statement within the same transaction.
SERIALIZABLE:
By forcing transaction ordering, making it impossible for them to conflict with each other. It will automatically add lock in sharemode after each select statement, applying a shared lock for each query operation. It may lead to a large number of lock waits. This isolation level is mainly used for distributed transactions of the InnoDB storage engine.
Note: Low-level transaction isolation can improve the concurrent access performance of transactions, but may lead to more concurrency problems (such as dirty reads, non-repeatable reads, phantom reads, etc.); high-level transaction isolation can effectively avoid concurrency problems, However, it will reduce the concurrent access performance of the transaction, which may lead to a large number of lock waits or even deadlocks.