Introduction of business
A transaction is a set of atomic SQL queries, or an independent unit of work. In short, all statements within a transaction are executed successfully or all execution fails.
In Mysql, transaction support is implemented at the engine layer, but not all Mysql engines support transactions. For example, MyISAM engine does not support transactions. This is one of the important reasons why MyISAM is replaced by InnoDB.
When it comes to affairs, we definitely think of ACID:
Atomicity Consistency Isolation Durability
Isolation level
When multiple transactions in the database are executed at the same time, problems such as dirty reads, non-repeatable reads, and phantom reads may occur, because there is the concept of transaction isolation level.
The SQL standard is defining four isolation levels:
READ UNCOMMITTED (Uncommitted read)
Modifications in the transaction, even if they have not yet been committed, are visible to other transactions. The transaction can read uncommitted data, also known as dirty read (Dirty Read).
READ COMMITTED
After a transaction is committed, the changes made can be seen by other transactions. This level is also called non-repeatable read, because if the same query is executed twice in a transaction, the results may be different.
REPEATABLE READ (repeatable read)
During the execution of a transaction, it is always consistent with the data seen at the start of the transaction. Of course, at this level, uncommitted data changes are also invisible to other transactions.
SERIALIZABLE (serializable)
For the same row of records, both write and read are locked. When a read-write lock conflict occurs, the transaction that is accessed later must wait for the completion of the previous transaction before it can continue, which will cause a lot of timeout and lock contention problems.
In terms of implementation, a view will be created in the database, and the logic of the view will prevail when accessing.
Under the repeatable read isolation level, this view is created when the transaction is started, and this view is used throughout the transaction.
Under the isolation level of read commit, this view is created when the SQL statement starts to execute.
Under the isolation level of read uncommitted, the latest value on the record is directly returned, and there is no concept of view.
Under the serialized isolation level, locks are used directly to avoid parallel access.
The configuration method is to set the startup parameter transaction-isolation to the desired isolation level.
View current settings:
mysql> show variables like 'transaction_isolation';
+-----------------------+-----------------+
| Variable_name | Value |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+
1row in set (0.00sec)
In short, existence is reasonable, and different isolation levels are suitable for different scenarios. The specifics should be determined according to business scenarios.
Implementation of transaction isolation
In Mysql, in fact, each record update will also record a rollback operation at the same time, and the latest value on the record can get the value of the previous state through the rollback operation.
The system will automatically determine that when there are no transactions that need to roll back the log, it will delete the rollback log.
Why is it not recommended to use long transactions:
Long transactions mean that there will be very old transaction views in the system. Since these transactions can access any data in the database at any time, before the transaction is committed, the rollback records that may be used in the database must be retained, which will take up a lot of Storage space. At the same time, long transactions also occupy lock resources and may also bring down the entire library.
The way the transaction starts
Explicitly start the transaction statement, begin or start transaction, commit is commit, and rollback is used. set autocommit = 0, this command will turn off the automatic commit of the thread, which means that if a select statement is executed, the transaction will be started and will not be automatically committed until you actively execute commit or rollback, or disconnect.
Personal suggestion is to start the transaction explicitly through the first method to avoid the occurrence of long transactions.
In the case of set autocommit = 1, the transaction is explicitly started with begin, and the transaction is committed if commit is executed. If commit work and chain is executed, the transaction is committed and the next transaction is automatically started, which also saves the overhead of executing the begin statement again.
Query long transaction:
The following statement is to query the transaction that lasts more than 60s
mysql> select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60;
Empty set (0.00sec)
To sum up, in the development process, we try to minimize the use of long transactions. If it is unavoidable, ensure that the logical log space is large enough and support dynamic log space growth. Monitor the Innodb_trx table and find a long transaction alarm.
In addition, if you want to better improve your programming ability, learn C language and C++ programming! Overtaking in a curve, one step faster! I may be able to help you here~
UP has uploaded some video tutorials on learning C/C++ programming on the homepage. Those who are interested or are learning must go and take a look! It will be helpful to you~
Sharing (source code, actual project video, project notes, basic introductory tutorial)
Welcome partners who change careers and learn programming, use more information to learn and grow faster than thinking about it yourself!
Programming learning:
Programming learning:
