Mysql database transaction learning notes

Preface

The author has been studying mysql Business , So I want to write a blog to record the learning process . If there is a mistake , Please correct me

What is the business

	 A transaction is a collection of operations , The transaction will submit or revoke the operation request to the system as a whole ,
 That is, these operations either succeed at the same time , Or fail at the same time .

`

The nature of the transaction

There are four kinds of transactions , atomicity 、 Uniformity 、 Isolation, 、 persistence
Atomicity （A）： Transactions are the smallest and indivisible unit of operation , All or nothing , All or nothing
Uniformity （C）： Transactions transform the database from one state to another consistent state . Before and after transaction start , The database integrity constraint is not broken .
Isolation, （I）： The isolation mechanism provided by the database system , Ensure that transactions run in an independent environment that is not affected by external concurrent operations
persistence （D）： Once a transaction is committed or rolled back , Its changes to the data in the database are permanent

Concurrent transaction problems

• Dirty reading ： A transaction reads data that has not been committed by another transaction .
  
• It can't be read repeatedly ： A transaction reads the same record one after the other , But the data read twice is different , Call it non repeatable .
  The difference between a dirty read and an unrepeatable read is this ： The former reads uncommitted data from other transactions , The latter reads data that has been committed by other transactions .
  
• Fantasy reading ： A transaction queries the database twice according to a certain condition , The two queries have different number of bars , This phenomenon is called phantom reading . The difference between unrepeatable reading and phantom reading can be popularly understood as ： The first is that the data changed , The latter is that the number of rows of data has changed .
  

Transaction isolation level

In order to solve the problems caused by concurrent transactions , The transaction isolation level is introduced into the database . There are mainly the following ：

How things work

1. Atomic realization principle (undo log)

The key to atomicity , Is the ability to undo all successful executions when a transaction is rolled back sql sentence .InnoDB Rollback depends on undo log, When a transaction modifies the database ,InnoDB I'm going to generate the corresponding undo log. If the transaction fails or is invoked rollback, Causes the transaction to be rolled back , You can use undo log The information in rollback the data to what it looked like before the modification .

undo log Logical log , It records sql Execute the relevant information . When a rollback occurs ,InnoDB Will be based on undo log The content does the opposite of what it did before . about insert, The rollback is executed delete. about delete, The rollback is executed insert. about update, When rolling back, the reverse update, Change the data back .

2. The principle of persistence (redo log)

redo log, Redo log . It records the physical modification of the data page when the transaction is committed , It is used to achieve the persistence of transactions .

InnoDB As MySQL Storage engine for , Data is stored on disk , But if you need a disk every time you read or write data IO, It's going to be inefficient . So ,InnoDB Provides caching (Buffer Pool),Buffer Pool Contains a map of partial data pages on the disk , As a buffer to access the database . When reading data from a database , Will start with Buffer Pool Read from , If Buffer Pool There is no , Is read from disk and put in Buffer Pool. When writing data to a database , Will first write Buffer Pool,Buffer Pool The modified data is periodically flushed to disk （ This process is called brushing ）.

Buffer Pool Has greatly improved the efficiency of reading and writing data , But it also raises new questions ： If MySQL Downtime , And then Buffer Pool The modified data in has not been flushed to disk , This results in the loss of data , The durability of transactions cannot be guaranteed .

therefore ,redo log Was brought in to solve the problem . When data is modified , In addition to modify Buffer Pool Data in , Also in the redo log Record this operation . When the transaction commits , Would call fsync The interface of redo log To brush plate . If MySQL Downtime , It can be read on reboot redo log Data in , Restore the database .redo log It's using WAL（Write-ahead logging, Pre written logs ）, All changes are written to the log first , Update to Buffer Pool, It guarantees that the data will not be affected MySQL Down and lost , This satisfies the persistence requirement .

since redo log You also need to write the log to disk when the transaction commits , Why is it better than direct Buffer Pool The modified data is written to disk in ( The brush is dirty ) Faster? ？ There are two main reasons ：

• Brush dirty is random IO, Because the data location is random for each change , But to write redo log It's an append operation , It belongs to order IO.
• Scrubbing is a data page （Page） Unit ,MySQL The default page size is 16KB, One Page The last small change was written on the entire page . and redo log Contains only the parts that really need to be written , Invalid IO Greatly reduce .

3. The principle of isolation （ Lock and MVCC）

Isolation seeks mutual noninterference between transactions in concurrent situations . Simplicity , We mainly consider the simplest read and write operations ( Special read operations, such as lock read, will be specified ), So isolation , There are two main aspects .

The first on the one hand, ,( A business ) Write operations on ( Another business ) The impact of write operations ： The lock mechanism guarantees isolation . Specific to see ： The database lock

In the second ,( A business ) Write operations on ( Another business ) The effect of read operations ：MVCC Ensure isolation .
MVCC Full name Multi-Version Concurrency Control, Multiple versions of the concurrency control protocol . Its biggest advantage is that it is read without lock , So there is no conflict between read and write , Good concurrency performance .InnoDB Realization MVCC, Multiple versions of data can coexist , It is mainly based on the following technology and data structure ：

• Hide columns ：InnoDB There are hidden columns for each row of data in , Hide the transaction that contains the data of this line in the column id、 Point to undo log Pointer of .

• be based on undo log Version chain of ： The hidden column of each row of data contains a pointer to undo log The pointer to , And each one undo log It will also point to earlier versions of undo log, So as to form a version chain .

• ReadView： By hiding columns and version chains ,MySQL You can restore the data to the specified version . But to which version , According to ReadView To make sure . So-called ReadView, It means business （ Do business A） Give the whole transaction system at one time （trx_sys） Snapshot , And then when you do the read operation , Will read the transaction in the data id And trx_sys Snapshot comparison , So as to judge whether the data is correct for the ReadView Whether or not visible , That is to say, to the transaction A Whether or not visible .

Hide columns

Version chain

readview

4. Principle of consistency

so to speak , Consistency is the ultimate goal of the transaction pursuit . The atomicity mentioned earlier 、 Persistence and isolation , It's all about keeping the state of the database consistent . Besides , In addition to database level security , The implementation of consistency also needs to be guaranteed at the application level . Measures to achieve consistency include ：

• Guaranteed atomicity 、 Persistence and isolation , If these features are not guaranteed , Nor is the consistency of transactions guaranteed .

• The database itself provides security , For example, string values are not allowed to be inserted into a plastic column 、 String length cannot exceed column limits, etc .

• Application level guarantee , For example, if a transfer operation only deducts the balance of the transferor , Without increasing the recipient's balance , No matter how well the database is implemented , There's no guarantee that the states are consistent .