MySQL--Detailed explanation of transaction operations (including MySQL engine)

First of all, if we only talk about MySQL transaction operations and not the MySQL engine, it is ignorant and rogue. Next, let's talk about the MySQL engine first.

MySQL common engine
  1. InnoDB storage engine
    InnoDB is the preferred engine for transactional databases, supporting transaction security tables (ACID) , row locking and foreign keys, and the InnoDB storage engine is the default engine for MySQL
  2. MyISAM storage engine
    MyISAM is based on the ISAM storage engine and extends it. It is one of the most commonly used storage engines in the Web, data warehousing and other application environments. MyISAM has high insertion and query speed, but does not support transaction operations .
  3. MEMORY storage engine The
    MEMORY storage engine stores the data in the table in memory, provides fast access without querying and referencing other table data, but does not support transaction operations .
Specific comparison of MySQL common engines

Insert picture description here
Conclusion: According to the comparison of the above figure, transaction operations only exist under the InnoDB storage engine, and other database engines do not support MySQL transaction operations.

OK, based on the above conclusions we will continue to talk about affairs.

Transaction operations only exist under the InnoDB storage engine

Next formally enter the MySQL transaction

  1. Transaction definition
    Full English name: Transaction
    transaction: a smallest indivisible unit of work; usually a transaction corresponds to a complete business (for example, bank account transfer business, which is the smallest unit of work)
  2. Under the InnoDB storage engine, what are the application scenarios of transactions?

A. Under the InnoDB storage engine, DML (insert, update, delete) addition, deletion and modification operations will automatically trigger transaction operations;
B. Common application scenarios at work also include: points exchange, bank transfer and other scenarios

  1. Four characteristics of transactions

Atomicity (A): The transaction is the smallest unit and cannot be divided.
Consistency (C): When the transaction requires all DML statements to operate, it must be guaranteed to succeed or fail at the same time.
Isolation (I): Between transaction A and transaction B Isolation
Persistence (D): It is the guarantee of the transaction, the sign of the end of the transaction (the data in the memory is persisted to the hard disk file)

  1. Terms for common things include:

Start transaction: Start Transaction
End of transaction: End Transaction
Commit transaction: Commit Transaction
Rollback transaction: Rollback Transaction

  1. Transaction operation commands include:

Transaction start: begin or start transaction
transaction commit: commit
transaction rollback: rollback

  1. Sign of things open

Under the InnoDB engine, any DML statement (insert, update, delete) is executed to mark the opening of the transaction

  1. Sign of the end of the transaction

Submit: Successfully end, synchronize all DML statement operation history records and underlying hard disk data at one time
Rollback: Failed end, clear all DML statement operation history records

  1. Things and the underlying data of the database

In the process of the transaction, the DML statement will not change the underlying data before the end, but just record the historical operation and complete the recording in the memory. Only at the end of the transaction, and when the end is successful, will the data in the underlying hard disk file be modified

  1. Isolation characteristics of things (I will focus on today)
    There is a certain degree of isolation between thing A and thing B, namely: isolation between different transaction operations; under the
    InnoDB engine, MySQL’s common transaction isolation level

Isolation has isolation levels (4)
. Read uncommitted: read uncommitted
Read committed: read committed
Repeatable read: repeatable read
Serialization: serializable

1、 read uncommitted

  • Things A and B, the uncommitted data of thing A, thing B can read
  • The data read here is called "dirty data"
  • This isolation level is the lowest, this level generally exists in theory, the database isolation level is generally higher than this level

2、read committed

  • Things A and B, the data submitted by thing A, thing B can read
  • This isolation level is higher than read uncommitted
  • In other words, the data after the other party’s transaction is submitted can only be read by my current transaction
  • This level can avoid "dirty data"
  • This isolation level will lead to "non-repeatable read"
  • Oracle default isolation level

3、repeatable read

  • Transaction A and transaction B, the data after transaction A commits, transaction B cannot read

  • Transaction B is repeatable read data

  • This isolation level is higher than read submitted

  • In other words, I still cannot read the data submitted by the other party

  • This isolation level can avoid "non-repeatable read" and achieve repeatable read

  • For example, the data read at 1 o'clock and 2 o'clock are the same

  • MySQL default level
    Insert picture description here

  • Although repeatable reading can be achieved, it will lead to "phantom reading"

4、serializable

  • Transaction A and transaction B. When transaction A is operating the database, transaction B can only wait in line
  • This isolation level is rarely used, throughput is too low, and user experience is poor
  • This level can avoid "phantom reads", each read is the real data in the database, transaction A and transaction B serial, not concurrent
Expansion:
Set isolation level

Method 1:
You can use the transaction-isolation option in the my.ini file to set the default transaction isolation level of the server.

This option value reference:
– READ-UNCOMMITTED
– READ-COMMITTED
– REPEATABLE-READ (default isolation level)
– SERIALIZABLE

In the my.ini file:

[mysqld]
transaction-isolation = READ-COMMITTED

Method 2:
Set the isolation level dynamically through commands

The isolation level can also be set dynamically in the running server, and the SET TRANSACTION ISOLATION LEVEL statement should be used.

Its grammar format reference:

  SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL <isolation-level>(隔离级别)

The isolation level can be:
– READ UNCOMMITTED
– READ COMMITTED
– REPEATABLE READ
– SERIALIZABLE
• For example: SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

Set the scope of the MySQL transaction isolation level

• The scope of the transaction isolation level is divided into two types:
– Global level: valid for all sessions
– Session level: only valid for the current session
• For example, set the session isolation level to READ COMMITTED:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
Or:
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
• Set the global isolation level to READ COMMITTED:
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

Jimmy_Wang's message:

If you can calm down and see the end of the article, you can only say that we are too destined. I have provided the information you need, follow me, like and forward to encourage me, so that we can continue to grow and progress.

Guess you like

Origin blog.csdn.net/qq_41475067/article/details/112847839