[MySQL series] Learning of MySQL transaction management (1) _ transaction concept | transaction operation mode | transaction isolation level

The content of the "Preface" article is roughly MySQL transaction management.

"Attribution Column" MySQL

"Home Page Link" Personal Home Page

"Author" Mr. Maple Leaf (fy)

1. Business concept

transaction concept

• A MySQL transaction refers to a series of database operations (a set of DMLstatements) that either all execute successfully or all fail and are rolled back. The purpose of transactions is to ensure the consistency and integrity of the database
• A transaction is something to be done or done, and is mainly used to process data with large operations and high complexity.
• Assume an order payment scenario for an e-commerce website. In this scenario, order payment involves multiple steps and operations on multiple data tables, such as order tables, inventory tables, and payment record tables.
• For example, when the user clicks the payment button, a transaction is started, and then the operations of creating an order, deducting inventory, and creating a payment record are executed in sequence. If any of these operations fails, the entire transaction will be rolled back, the order will not be created, the inventory will not be deducted, and the payment record will not be created. Only when all operations are successfully executed, the transaction will be submitted and the order payment is completed.
• In this way, multiple MySQL statements are required, and all these operations combined form a transaction.
• Recall DML again: DML【data manipulation language】Data Manipulation Language, which represents instructions used to operate on data: insert，delete、update. DML is divided into a separate one DQL, data query language, which represents instructions:select

MySQL may have a large number of transactions at the same time. If these transactions are not controlled, problems may occur during execution.

Each transaction has at least one SQL or many SQLs, so if everyone accesses the same table data, there will definitely be problems without protection. Even, because the transaction is composed of multiple SQLs, there will be cases where an error occurs halfway through the execution or you don’t want to execute it anymore, so what should you do if it has already been executed?

Therefore, a complete transaction is not a simple SQL set. The transaction also needs to satisfy the following four attributes:

• Atomicitytransaction : All operations in a transaction ( ) are either completely completed or not completed, and will not end in any intermediate link. If an error occurs during the execution of the transaction, it will be rolled back ( Rollback) to the state before the transaction started, as if the transaction had never been executed.
• Consistency : The integrity of the database is not compromised before the transaction begins and after the transaction ends. This means that the written data must fully comply with all preset rules, including the accuracy of the data, seriality and the subsequent database can spontaneously complete the scheduled work
• Isolation : The ability of the database to allow multiple concurrent transactions to read, write and modify its data at the same time. Isolation can prevent data inconsistency caused by cross-execution when multiple transactions are executed concurrently. Transaction isolation is divided into different levels, including read uncommitted ( Read uncommitted), read committed ( read committed), repeatable read ( repeatable read) and serialized ( Serializable)
• Durability : After the transaction is completed, the modifications to the data are permanent and will not be lost even if the system fails.

The abbreviations of the above four attributes are ACID:

• Atomicity ( Atomicity, also known as indivisibility)
• Consistency ( Consistency)
• Isolation ( Isolationalso known as independence)
• persistence( Durability)

Why do things happen

• Transactions were designed by MySQL writers, essentially so that when applications access the database, transactions can simplify our programming model and eliminate the need for users to consider various potential errors and concurrency issues themselves.
• If MySQL simply provides data storage services, then users need to consider various potential problems when accessing the database, including network abnormalities, server downtime, etc.
• Therefore, the essence of transactions is to serve applications, and is not inherent with the database system. After using the database for a period of time, it was discovered that transactions are needed. The writers of MySQL encapsulated and supported transactions.

2. Transaction version support

In MySQL, only databases or tables using Innodbthe database engine support transactions. Transactions MyISAMare not supported.

Check MySQL's database engine through the following command to see which engines support transactions

show engines;

illustrate:

• Transactions: Indicates whether the storage engine supports transactions. You can see that InnoDBthe storage engine supports transactions, but the MyISAM storage engine does not support transactions.

3. Transaction submission method

There are two common submission methods for transactions, namely automatic submission and manual submission.

View how the transaction was submitted:

show variables like 'autocommit';

Note: ONIndicates that auto-commit is turned on, and the value is OFFindicates that auto-commit is turned off, that is, the transaction submission method is manual submission.

It can be SETused to change the auto-commit mode of MySQL.

SET AUTOCOMMIT=0; --禁止自动提交
SET AUTOCOMMIT=1; --开启自动提交

Note: Setting it to 0 means turning off automatic submission, which is equivalent to setting the transaction submission method to manual submission.

4. Common operation methods of transactions

In order to facilitate the demonstration, it is necessary to set the isolation level of MySQL to read uncommitted , that is, to set the isolation level to be relatively low, so that it is convenient to see the experimental phenomenon

The isolation levels are: (the isolation level increases in turn, and the read uncommitted isolation level is the lowest)

1. Read Uncommitted( Read uncommitted)
2. ReadCommit( read committed)
3. Repeatable read ( repeatable read)
4. serialize( Serializable)

Set the lowest isolation level:

set global transaction isolation level read uncommitted;

Notice: After setting the global isolation level, the isolation level of the current session will not change, but will only affect subsequent new connections to MySQL, so you need to restart the terminal to see that the session isolation level is successfully set

After restarting the client, log in again and see the following:

Then create a test table

create table if not exists account(
id int primary key,
name varchar(50) not null default '',
blance decimal(10,2) not null default 0.0
)ENGINE=InnoDB DEFAULT CHARSET=UTF8;

4.1 Normal operation of transactions

Test 1

Start two terminals, and each terminal starts a transaction (it is okay not to start the transaction on the right). To start the transaction, use any of the following commands:

begin;
-- or
start transaction；

After starting the transaction, there is no data in the query table.

Note: The transaction submission method here is automatic submission.

The transaction in the left terminal uses savepointthe command to create a save point. This command is used to set a save point.

savepoint 保存点名字;

Insert a piece of data in the left terminal, and you can view the record inserted into the table by the transaction in the left terminal in the right terminal. The

transaction in the left terminal uses savepointthe command to create a save point, and then continues to insert a record into the table. At this time , You can also see the newly inserted record (read uncommitted) in the right terminal. Use the command to roll back the

transaction in the left terminal.rollback

rollback to 保存点; -- 事务回滚到该保存点
rollback;          -- 默认回滚到事务的最开始

The transaction is rolled back to save point s2. At this time, the right terminal cannot see the second record just inserted when viewing the data in the table. The

transaction in the left terminal directly uses rollbackthe command to roll back to the beginning of the transaction, and the right terminal queries the data. Empty

Use committhe command to commit the transaction (representing the end of a transaction), and it cannot be rolled back after the transaction is committed

Notice: Once a transaction is committed, it cannot be rolled back, and rollbackit cannot be rolled back again.

The above is the normal situation of transaction operations, and transactions are more to deal with abnormal situations, such as the MySQL client suddenly crashes, accidentally shutting down, etc.

4.2 Transaction exception verification

Demonstration 1 (reflecting the atomicity of transactions)

Purpose: To prove that the transaction is not committed commit, the client crashes, and MySQL will automatically roll back (the isolation level is set to read uncommitted, and the transaction commit method is autocommit)

Both terminals start a transaction each, and there is a piece of data in the table in advance (it is okay if the transaction is not started on the right side). The

transaction in the left terminal inserts a record into the table. Since the isolation level is read uncommitted, it can be queried in the right terminal. When reaching the inserted record,

the client on the left exits abnormally ctrl + \(without committing the transaction).

As a result, MySQL will automatically roll back the transaction to the beginning. At this time, the previously inserted record will no longer be visible in the right terminal.

Demo 2 (reflecting the persistence of transactions)

Purpose: To prove the transaction commit. Even if the client crashes, the MySQL data will not be affected. The data has been persisted (saved to disk) . (The isolation level is still set to read uncommitted, and the transaction submission method is automatic submission)

Both terminals start a transaction each (the right side does not start the transaction).

The transaction in the left terminal inserts a record into the table. Since the isolation level is read uncommitted, the inserted record can be queried in the right terminal

. The terminal commits the transaction and then exits abnormally.

You can still see the previously inserted records in the right terminal, because the data is persisted after the transaction is submitted.

Even if the automatic transaction submission is turned off, committhe data is still persisted. Experiment 3 below is used to verify

Demonstration 3 (verification experiment)

Purpose: To prove that beginthe operation will automatically change the submission method and will not be affected by whether MySQL automatically submits or not.

Turn off automatic submission

set autocommit = 0;

Start a transaction in the left terminal and insert a new record into the table (a transaction can also be started on the right). Since the isolation level is read uncommitted, the newly inserted record can be queried in the right terminal. The left terminal commits the transaction

. , and then exit abnormally, you can still see the previously inserted records in the right terminal, because the data is persisted after the transaction is committed

The above description: Transactions started using the beginor start transactioncommand must be commitmanually submitted using the command before the data will be persisted, regardless of whether it is set or autocommitnot

Demo 4

Purpose: To prove the relationship between a single SQL statement and a transaction

The terminals on the left and right sides both turn off automatic submission, and the right side does not need to be turned off (the right side does not affect the operation)

set autocommit = 0;

Without starting the transaction, directly delete a piece of data. Since the isolation level is read uncommitted, the terminal on the right can also see the results.

After executing a single SQL statement, the client on the left directly exits abnormally; while the deleted data on the terminal on the right is rolled back. The terminal on

the left turns on automatic submission, and the terminal on the right does not affect the operation

set autocommit = 1;

Without starting the transaction, directly delete a piece of data. Since the isolation level is read uncommitted, the terminal on the right can also see the results. After

executing a single SQL statement, the client on the left directly exits abnormally, and the data on the right has not changed, that is, the terminal on the left The operation was not rolled back.

The experimental results illustrate: In fact, we have been using single SQL transactions before, but autocommitit is turned on by default, so the single SQL transaction is automatically submitted after execution.

• Whether the global variable autocommitis set or not affects a single SQL statement, and InnoDBeach SQL statement in it will be encapsulated into a transaction by default
• If autocommitit is ON, then a single SQL statement will be automatically submitted after execution. If it is , then manual submission OFFis required after the SQL statement is executed . If it is not submitted manually, the executed SQL will be rolled back.commit

The above experimental conclusions

• As long as you enter beginor start transaction, the transaction must be commitsubmitted before it will be persisted, regardless of whether it is set set autocommit.
• Transactions can be rolled back manually, and at the same time, when the operation is abnormal, MySQL will automatically roll back
• Each InnoDBSQL statement is encapsulated into a transaction by default and automatically submitted (select has special circumstances because MySQL has it MVCC, discussed below)
• The above experiment reflects the atomicity ( rollback) and durability ( commit) of the transaction itself

Notes on transaction operations

• If no savepoint is set, you can also roll back, but only to the beginning of the transaction. Use it directly rollback(provided the transaction has not been committed yet)
• If a transaction is committed ( commit), it cannot be rolled back ( rollback)
• The transaction can choose which save point to roll back to (provided that the transaction has not yet been committed)
• InnoDBSupport transactions, MyISAMdo not support transactions

5. Transaction isolation level

• The MySQL service may be accessed by multiple client processes (threads) at the same time, and the access is conducted in a transactional manner.
• A transaction may be composed of multiple SQL statements, which means that any transaction has three stages before execution, during execution and after execution.
• The so-called atomicity is to allow the user layer to see either before execution or after execution. If there is a problem during execution, it can be rolled back at any time. Therefore, the characteristic of a single transaction for users is atomicity.
• But after all, each transaction has an execution process. When multiple transactions execute multiple SQL statements of their own, mutual influence may still occur. For example, multiple transactions access the same table at the same time, or even the same table in the table. a record
• In order to ensure that the database is as uninterrupted as possible during transaction execution, isolation appears
• In order to allow the database to be interfered with to varying degrees during the execution of transactions, isolation levels appeared.

Isolation level: (increase in order)

1. Read uncommitted ( Read Uncommitted): At this isolation level, all transactions can see the uncommitted execution results of other transactions (it is impossible to use this isolation level in actual production), but it is equivalent to no isolation, and there will be Many concurrency problems, such as dirty reads, phantom reads, non-repeatable reads, etc., we used this isolation for the convenience of experiments
2. Read-commit ( Read Committed): This isolation level is the default isolation level for most databases (not the MySQL default
   ). It meets the simple definition of isolation: a transaction can only see changes made by other committed transactions . This isolation level will cause non-repeatable reads, that is, when a transaction is executed, if you select multiple times, you may get different results.
3. Repeatable read ( Repeatable Read): This is the default isolation level of MySQL. It ensures that when the same transaction reads operation data multiple times during execution, the same data rows will be seen , but there will be phantom reading problems.
4. Serialization ( Serializable): This is the highest isolation level for transactions. It solves the problem of phantom reads by forcing transactions to be ordered so that they cannot conflict with each other. It adds a shared lock to each read data row, but may cause timeouts and lock competition (this isolation level is too extreme and is rarely used in actual production)

Isolation levels are basically implemented through locks. Different isolation levels require different use of locks. Common ones include table locks, row locks, read locks, write locks, gap locks ( GAP), Next-Keylocks (GAP + row locks), etc.

5.1 View and set isolation

View global compartment levels

select @@global.tx_isolation;

View the current session isolation level

select @@session.tx_isolation;

You can also use the following command to view the isolation level of the current session

select @@tx_isolation;

Set the current session isolation level

set session transaction isolation level 隔离级别;

For example, to set serialization for the current session

set session transaction isolation level serializable;

Note: Setting the isolation level of the current session will only affect the current session. New sessions will still use the global isolation level.

Set global isolation level

set global transaction isolation level 隔离级别;

For example, setting global repeatable read

Notice: Setting the global isolation level will affect subsequent new sessions, but will not affect the current session. If you need to make the global isolation level take effect, you need to restart the client. The following is an

experimental demonstration to demonstrate the four isolation levels.

5.2 Read Uncommitted

Start two terminals, set the isolation level to read uncommitted, and then view the data in the table

set session transaction isolation level read uncommitted;

The left and right terminals each start a transaction, the left terminal modifies the data in the table, the transaction of the left terminal is not submitted, and the transaction of the right terminal can see the modified data

illustrate：

• Like this, when a transaction is executing, it reads the update (or other operations) of another transaction in execution but not the commitdata. This phenomenon is called dirty reading ( dirty read)
• Read uncommitted is the lowest isolation level for transactions, and there is almost no locking. Although it is efficient, it has many problems, so it is seriously not recommended to use it.

5.3 Read Committed

Start two terminals, set the isolation level to read-commit, and then view the data in the table.

Each of the two terminals starts a transaction. The left terminal modifies the data in the table. Before the left terminal transaction is submitted, the right terminal transaction cannot be viewed. Modification results of data to another transaction

Only when the transaction in the left terminal commits, the transaction in the right terminal can see the modified data

illustrate：

• Like this, the current transaction has not commitcommitted the transaction with the current transaction for two time periods, and another transaction reads different values ​​​​in these two time periods. This phenomenon is called non-repeatable read ( non reapeatable read)
• This phenomenon may lead to data consistency problems, because a transaction reads different data values ​​at different points in time, which may produce wrong calculation results or logic errors. This isolation level is not recommended

5.4 Repeatable Read

Start two terminals, set the isolation level to repeatable read, and then view the data in the table. The two terminals each start a transaction. The modifications made by the transaction in the left terminal cannot

be seen before the transaction in the right terminal is submitted.

After the transaction in the left terminal is committed, the transaction in the right terminal still cannot see the modified data.

Only after the transaction in the right terminal commits the transaction, and then view the data in the table, can the data in the table be seen.

illustrate：

• Like the above, it is called repeatable read
• However, when a general database is in a repeatable read situation, updatethe data satisfies repeatable reading, but insertthe data will have a phantom read problem, because isolation is achieved by locking the data, and the newly inserted data does not originally exist. Therefore, general locking cannot shield such problems
• But MySQL solves the phantom read problem under the repeatable read isolation level (through Next-Keylock ( GAP+ row lock) to solve the phantom read problem)
• Phantom reading: During the execution of a transaction, the same select statement query obtains different data (new data appears), which is like an illusion. This phenomenon is called phantom reading.

The following demonstrates that MySQL's repeatable reading does not have phantom reading problems.

Start two terminals, set the isolation level to repeatable read, and then view the data in the table. Then

each of the two terminals starts a transaction. The left terminal inserts new data into the table and submits the transaction. The transaction in the right terminal is still not visible. Newly inserted data (proof that there is no phantom reading problem)

5.5 Serializable

Start two terminals, set the isolation level to serialization, and then view the data in the table.

Then each of the two terminals starts a transaction. If both transactions perform read operations on the table, then the two transactions can be concurrent. Execution will not be blocked.

If one of the two transactions wants to write to the table, then this transaction will be blocked immediately.

Until the right terminal transaction is submitted, the left terminal transaction can modify the table.

illustrate：

• There will be no problem if all operations are locked and serialized, but as long as they are serialized, the efficiency is very low and will almost never be used.

5.6 Summary of isolation levels

• The stricter the isolation level, the higher the security, but the lower the concurrency performance of the database. It is often necessary to find a balance point between the two.
• The default isolation level of mysql is repeatable read. Generally, do not modify it.

The isolation levels are summarized as follows:

6. Consistency

As a result of transaction execution, the database must change from one consistent state to another. A database is in a consistent state when it contains only
the results of successfully committed transactions.

• If an error occurs during the execution of a transaction, it needs to be automatically rolled back to the initial state of the transaction, as if the transaction had never been executed. That is, consistency requires atomicity to ensure
• After the transaction is completed, the modification to the data must be permanent and cannot be lost even if the system fails. That is, consistency requires durability to ensure
• When multiple transactions access the same data at the same time, it must be ensured that when multiple transactions are executed concurrently, data inconsistency will not be caused by cross-execution. That is, consistency requires isolation to ensure
• In fact, consistency is strongly related to the user's business logic. Generally, MySQL provides technical support, but consistency still needs to be supported by the user's business logic. In other words, consistency is determined by the user.
• Technically, consistency requires atomicity, durability, and isolation to ensure

--------------------- END ----------------------

「 作者 」 枫叶先生
「 更新 」 2023.9.7
「 声明 」 余之才疏学浅，故所撰文疏漏难免，
          或有谬误或不准确之处，敬请读者批评指正。