Summary of ACID characteristics and concurrency issues of MySQL transactions

This article brings you relevant knowledge about mysql. It mainly introduces the ACID characteristics of MySQL transactions and concurrency problem solutions. The article provides a detailed introduction around the topic, which has certain reference value. , friends who need it can refer to it, I hope it will be helpful to everyone.

Recommended learning: mysql video tutorial

1. The concept of transaction

A transaction is An indivisible unit composed of one or more SQL statements that operate on the database. Only when all operations in the transaction are executed normally, the entire transaction will be submitted to the database. If some transaction processing fails, then the transaction will be To roll back to the original state , therefore, either all transactions succeed or all fail.

So we need to remember a few basic concepts of transactions, as follows:

A transaction is the execution of a set of SQL statements, either all succeed or all fail, and no part of it can appear Success, partial failure results, atomic operations that guarantee transaction execution. Only when all SQL statements of the transaction are successfully executed can the transaction be committed and the results written to the disk. During transaction execution, if some SQL errors occur, the transaction must be rolled back to the original state.

For example, the transfer business requires multiple SQL statements to be completed together. Only when these SQL statements are executed successfully can the business be considered successful.

Transaction processing has three states:

begin: Open all sql statements to be executed in a transaction All are successful, and then commit commits a transaction. If any of the SQL statements causes an abnormal SQL execution due to a power outage or server error, the transaction will not be submitted and the transaction will be rolled back (rollback), the data will be restored to the state before the transaction started

This is guaranteed by the storage engine (guaranteed by redo log and undo log)

MyISAM storage engine does not support transactions, while InnoDB storage engine supports transactions and row locks.

Use show engines\G to check which storage engines are supported by the current database.

select @@autocommit;View settings for transaction commit status

Database engine It can be modified temporarily through commands or permanently through configuration files.

If our business involves transactions, we usually control this variable in code. Generally speaking, our transactions consist of multiple SQLs and must satisfy the atomic operation of the transaction, so we set it to Submit manually. If the business is successful, the transaction will be submitted; if there is a failure in the middle of the business, one transaction will be rolled back.

2. ACID characteristics

Every transaction must meet the following 4 characteristics:

Atomicity of transactions(Atomic): A transaction is an indivisible whole. The transaction must have atomic characteristics, and when the transaction is modified, either all will be executed or none will be executed, that is, the completion of the transaction part is not allowed. Transaction Consistency(Consistency):Before and after a transaction is executed, the database data must maintain a consistent state. The consistency state of the database must be the responsibility of the user and implemented by the concurrency control mechanism. Take online shopping as an example. Only by letting the goods leave the warehouse and entering the customer's shopping cart can a complete transaction be completed. (Consistency is not only reflected in transactions, but also includes the introduction of MySQL in the storage layer. In order to improve the access efficiency of hotspot data, a cache layer Redis or Memery cache is generally added to cache the hotspot data, which involves the data of the cache layer and the database DB layer. Consistency issue) Transaction Isolation(Isolution): When two or more transactions are executed concurrently, in order to ensure data security, the operations within one transaction are isolated from the operations of other transactions. Not visible to other executing transactions, prevents concurrently executing transactions from affecting each other. Isolation level: data security and transaction concurrency. The stricter the isolation, the higher the security, and the lower the concurrency (that is, concurrency control, ensuring data security) Durability (Durability) of the transaction: After the transaction is completed (transaction commit is successful), the DBMS guarantees Its modifications to the data in the database are permanent. Even if the database fails due to a failure, the data should be able to be restored.

The most important thing about MySQL is the log, not the data!

The ACD feature of transactions is guaranteed by MySQL's redo log and undo log mechanisms; I isolation is guaranteed by the lock mechanism of mysql transactions.

3. Problems with transaction concurrency

Transaction processing is not isolated, and the following problems usually occur when executing transactions concurrently:

Dirty Read: One transaction reads uncommitted data from another transaction. For example, when transaction A and transaction B are executed concurrently, after transaction A is updated, transaction B queries and reads A's uncommitted data. At this time, transaction A rolls back, and the data read by transaction B is invalid dirty data (

Transaction B read the uncommitted data of transaction A)Non-repeatable read(NonRepeatable Read): The operation of one transaction caused another transaction to read different data twice before and after. For example, when transaction A and transaction B are executed concurrently, after transaction B queries and reads data, transaction A updates the data queried by transaction B. At this time, transaction B reads the data again and finds that the data read twice are different. Same. (Transaction B read the submitted data of transaction A)Phantom Read(Phantom Read)Phantom Read: The operation of one transaction results in the amount of data resulting from two queries before and after another transaction different. For example, when transaction A and transaction B are executed concurrently, after transaction B queries and reads data, transaction A adds or deletes a record that meets the query conditions of transaction B. At this time, transaction B queries again and finds that the previous query does not Existing records, or some records from the previous query are missing. (Transaction B has read the newly added data of transaction A or cannot read the data deleted by transaction A)

Dirty reading must be eliminated because the transaction is not committed. In some scenarios, non-repeatable reads and phantom reads are allowed (the transaction has been committed), but do not necessarily have to be eliminated (by setting different isolation levels), which is determined by the application scenario requirements.

4. Transaction related commands

select @@autocommit;Check whether MySQL automatically commits transactions

0 means manual submission of transactions, 1 means automatic submission of transactions, set the transaction submission method to manual submission (only affects the current session):

Recommended learning:

mysql video tutorial

The above is the detailed content of Summary of ACID characteristics and concurrency issues of MySQL transactions. For more information, please follow other related articles on the PHP Chinese website!