1. In MySQL, transaction support is implemented at the engine layer. MySQL is a system that supports multiple engines, but MySQL's native MyISAM engine does not support transactions, which is one of the important reasons why MyISAM was replaced by InnoDB.
2. Transaction characteristics: ACID (Atomicity, Consistency, Isolation, Durability, namely atomicity, consistency, isolation, durability). Today, InnoDB is used as an example to discuss "isolation".
3. When multiple transactions are executed on the database at the same time, there may be problems of dirty read (dirty read), non-repeatable read (non-repeatable read), phantom read (phantom read), in order to solve these problems, there are The concept of "isolation level". The stricter the isolation, the lower the efficiency. Many times, we have to find a balance between the two.
4. SQL standard transaction isolation levels include: read uncommitted, read committed, repeatable read, and serializable:
- Reading uncommitted means that when a transaction has not been committed, the changes it made 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 read means that the data seen during the execution of a transaction is always the same as the data seen when the transaction is started. Of course, under the repeatable read isolation level, uncommitted changes are also invisible to other transactions.
- Serialization, as the name suggests, for the same row of records, "write" will add "write lock", "read" will add "read lock". When there is a read-write lock conflict, the later-accessed transaction must wait for the previous transaction to complete before it can continue.
Suppose there is only one column in the data table T, and the value of one row is 1, the following is the behavior of executing two transactions in chronological order.
mysql> create table T(c int) engine=InnoDB; insert into T(c) values(1);
What are the different return results of transaction A under different isolation levels, that is, what are the return values of V1, V2, and V3 in the figure?
- If the isolation level is "read uncommitted", the value of V1 is 2. At this time, although transaction B has not been submitted, but the result has been seen by A. Therefore, both V2 and V3 are also 2.
- If the isolation level is "read commit", then V1 is 1 and V2 is 2. The update of transaction B can only be seen by A after committing. Therefore, the value of V3 is also 2.
- If the isolation level is "repeatable read", V1 and V2 are 1, and V3 is 2. The reason why V2 is still 1 is to follow this requirement: the data seen by the transaction during execution must be consistent before and after.
- If the isolation level is "serialization", it will be locked when transaction B executes "change 1 to 2". Until transaction A is committed, transaction B can continue to execute. So from the perspective of A, the values of V1 and V2 are 1, and the value of V3 is 2.
The default isolation level of the Oracle database is actually "read commit", so for some applications that migrate from Oracle to MySQL, to ensure the consistency of the database isolation level, you must remember to set the isolation level of MySQL to "read commit". Configuration method: use show variables to view the current value; set the value of the startup parameter transaction-isolation to READ-COMMITTED;
mysql> show variables like 'transaction_isolation';
5. It is not recommended to use long transactions: (not quite understand here)
Long transactions mean that there will be a very old view of transactions in the system. Because these transactions may access any data in the database at any time, before this transaction is committed, the rollback records it may use in the database must be retained, which will result in a large amount of storage space occupied; in addition to the impact on the rollback segment, long Transactions also take up lock resources and may drag down the entire library.
6. MySQL transaction startup methods are as follows:
-
Explicitly start a transaction statement, begin or start transaction. The supporting commit statement is commit and the rollback statement is rollback.
-
set autocommit = 0, this command will turn off the automatic submission of this thread. This means that if you only execute a select statement, the transaction will start and it will not automatically commit. This transaction continues until you actively execute a commit or rollback statement, or disconnect.
Some client connection frameworks will execute a set autocommit = 0 command after the default connection is successful. This leads to the following queries are in the transaction, if it is a long connection, it leads to an unexpected long transaction.
Therefore, it is recommended to use set autocommit = 1 to start a transaction through an explicit statement.
But for a business that requires frequent use of transactions, the second method does not need to actively execute a "begin" at the beginning of each transaction, reducing the number of statement interactions. So if you struggle with the "one more interaction" problem, it is recommended to use the commit work and chain syntax. In the case of autocommit is 1, the transaction explicitly started with begin, commit the transaction if the commit is executed. If the 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. At the same time, the benefit is to clearly know whether each statement is in a transaction from the perspective of program development.
You can query long transactions in the innodb_trx table of the information_schema library. For example, the following statement is used to find transactions with a duration of more than 60s.
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60