MySQL transaction and its characteristics and locking mechanism

List of articles

• Fresh and fierce dry goods
• Transactions and their characteristics
  • Uniformity
  • Atomicity
  • Isolation,
  • persistence
• Concurrent transaction control
  • Single version control - lock
  • Multi version control -MVCC
• Atomic realization principle
• The principle of persistence
• Isolation implementation principle
• Principle of consistency implementation
• Get it done MySQL

Transactions and their characteristics

Everybody knows ACID ( Atomicity 、 Uniformity 、 Isolation and persistence )

A logical unit of work is to become a transaction , In relational database management system , Must satisfy 4 A feature

• Atomicity : All operations of the transaction , Or it's all done , Or not at all , It won't end in an intermediate link
• Uniformity : Before and after a transaction , The integrity limit of the database has not been broken
• Isolation, : The database system provides a certain isolation mechanism , Ensure that transactions are not affected by external concurrent operations “ Independent ” Environmental execution . This means that the intermediate state in the transaction process is not visible to the outside , vice versa
• persistence : After the transaction completes , Its modification of data is permanent , Even if there is a system failure, it can keep

ACID And the relationship between them is shown in the figure below , such as 4 One of the features is 3 One and WAL It matters , All need to pass Redo、Undo Log to ensure, etc .

Uniformity

Let's start with consistency , Consistency actually includes two parts , They are constraint consistency and data consistency .

• Constraint consistency ： It should be easy to think of the foreign key specified when creating the table structure in the database 、Check、 Unique index and other constraints . It's a pity that MySQL in , It is not supported Check Of , Only the other two are supported , So constraint consistency is very easy to understand .
• Data consistency ： It's a comprehensive rule , Or a rule to grasp the overall situation . Because it's atomic 、 persistence 、 The result of mutual assurance of isolation , Instead of just relying on one technology .

Atomicity

Atomicity is the two mentioned above “ or ”, That is, either change , Or not . In other words, users can't feel a changing state .MySQL It's through WAL（Write Ahead Log） Technology to achieve this effect .

Atomicity and WAL What does it matter ？

For example , If the transaction is committed , Then the changed data will take effect , If at this time Buffer Pool My dirty pages are not scrubbed , How to ensure that the changed data takes effect ？ You need to use Redo Data recovered from log . And if the transaction is not committed , And Buffer Pool The dirty pages have been scrubbed , How can the data that should not exist disappear ？ It needs to pass Undo To implement the ,Undo Again through Redo To ensure that the , So the ultimate guarantee of atomicity depends on Redo Of WAL Realized by mechanism .

Isolation,

The so-called isolation , It means that the execution of a transaction cannot be disturbed by other transactions , That is, the operation and data used in a transaction are isolated from other concurrent transactions . Lock and multi version control are compatible with isolation .

persistence

So called persistence , It means that once a transaction is committed , Its changes to the data in the database should be permanent , The next operation or failure should not have any impact on it . We already talked about that , The atomicity of a transaction can ensure that a transaction is either fully executed , Or features that don't execute at all , This can logically ensure that the user cannot see the intermediate state . But how is persistence guaranteed ？ Once the transaction is committed , Through atomicity , Even in case of downtime , You can also find the data logically and write it into the physical storage space again , This ensures that data will not be lost from both logical and physical aspects , That is to ensure the persistence of the database .

Concurrent transaction control

Single version control - lock

Locks are used exclusively to ensure that transactions are isolated from each other when there is only one version , So lock can be understood as single version control .

stay MySQL Transaction , The implementation of the lock is related to the isolation level , stay RR（Repeatable Read） Under isolation level ,MySQL In order to solve the problem of unreal reading , At the expense of parallelism , adopt Gap Lock to prevent data from being written , And this lock , Because its parallelism is not enough , There are many conflicts , Often cause deadlock .

Multi version control -MVCC

Multi version control is also called MVCC, In the database , In order to achieve high concurrency data access , Multi version processing of data , And through the visibility of transactions to ensure that transactions can see the data version they should see .

How are multiple versions generated ？ Every modification to the database , Will be in Undo The log records the transaction number of the current modification record and the storage address of the data state before modification （ namely ROLL_PTR）, So that you can roll back to the old data version if necessary . for example , A read transaction queries the current record , The latest transaction has not yet been committed , According to atomicity , Read transactions cannot see the latest data , But you can find the old version of data in the rollback segment , This generates multiple versions .

Multi version control skillfully converts the exclusive and mutual exclusion of scarce resources into concurrency , Greatly improve the database throughput and read-write performance .

Atomic realization principle

Every write transaction , Will be modified Buffer Pool, And the corresponding Redo journal , These log information will be recorded in ib_logfiles In file . because Redo The log is to follow Write Ahead Log It's written in , So transactions are recorded sequentially .

stay MySQL in , whatever Buffer Pool Before the pages in are flushed to disk , Will be written to the log file first , There are two guarantees .

• If Buffer Pool This page in failed to be swiped , At this point, the database is down , After the database starts again , Can pass Redo Log to recover it , To ensure that the data written on the dirty page will not be lost , So we have to make sure that Redo First write .
• because Buffer Pool The space of is limited , To load a new page , Need from LRU Eliminate some pages from the linked list , And these pages have to be swiped , Can be reused , Then the brush plate at this time , You need to ensure the corresponding LSN Your log should also be written in advance ib_logfiles in , If not , It happened that this transaction was not submitted , Database hung , After the database starts , This transaction cannot be rolled back . So if you don't write a log , The rollback log corresponding to these data may not exist , The uncommitted transaction cannot be rolled back , So atomicity cannot be guaranteed , So atomicity is through WAL To ensure that the

The principle of persistence

As shown in the figure below , One “ Submit ” The actions triggered by actions are ：binlog to ground 、 send out binlog、 Storage engine submit 、flush_logs, check_point、 Transaction commit flag, etc . These are databases to ensure their data integrity 、 The means of persistence .

How do these operations achieve persistence ？ I talked about it before. , Through atomicity, logical persistence can be guaranteed , The physical persistence can be guaranteed through the data disk brushing of the storage engine . This process is similar to that mentioned earlier Redo journal 、 State of affairs 、 Database recovery 、 Parameters
innodb_flush_log_at_trx_commit of , Also with binlog of . Here's one more thing , When the database is restored , If the status of a transaction is found to be Prepare, Will be in binlog Find the corresponding transaction in the database and re execute it in the database , To ensure the persistence of the database .

Isolation implementation principle

InnoDB The isolation supported is 4 Kind of , The isolation from low to high is ： Read uncommitted 、 Read the submission 、 Repeatable 、 Serializable .

1. Read uncommitted （RU,Read Uncommitted）. It can read the intermediate process of a transaction , Contrary to ACID characteristic , There's a problem with dirty reading , So I won't use , You can ignore .
2. Read the submission （RC,Read Committed）. It means that if other transactions have been committed , Then we can see , This is also one of the most widely applicable levels . But for some historical reasons , Probably RC Not much is used in a production environment .
3. Repeatable （RR,Repeatable Read）, Is currently the most used level . It is characterized by Gap lock 、 At present, it is still the default level 、 Deadlocks often occur at this level 、 Low concurrency and so on .
4. Serializable , This implementation , In fact, there are not many versions , Back to the state of single version , Because all of its implementations are implemented through locks .

When it comes to the implementation of isolation , We usually use Read View Represents the visibility of a transaction . As mentioned earlier RC High level transaction visibility , It can see all the changes of the committed transaction . and RR Level transactions , There is no such function , In a read transaction , No matter what changes are made to the data by other transactions , And whether to submit , As long as you don't submit , The data result of the query will not change . How can this be done ？

as time goes on , Read commit: each read operation statement will get a Read View, After each update , Will get the latest transaction submission status in the database , You can also see the latest committed transaction , That is, each statement execution will update its visibility view . In contrast, repeatable , This visibility view , Only after you commit your current transaction , To update , So it has nothing to do with other affairs .

stay RR Below grade , Long uncommitted transactions will affect the performance of the database PURGE operation , This will affect the performance of the database , So you can add a monitor to such transactions .

Serialization is achieved through locks , So it's not actually multi version control , Its characteristics are also obvious ： Read the lock 、 Single version control 、 Low concurrency .

Principle of consistency implementation

Consistency can be summarized as data integrity . Data integrity is guaranteed by three other features , Including atomicity 、 Isolation, 、 persistence , And these three characteristics , Again through Redo/Undo To ensure that the , In order to ensure the integrity of the data , Put forward three characteristics , These three features are realized by the same technology , So understand Redo/Undo To understand the nature of the database .

As shown in the figure above , Logical consistency , Include unique index 、 Foreign key constraints 、check constraint , It's business logic .