MySql isolation level and the transaction log

MySql transaction isolation level to resolve

First, log

1. the binlog (logical log)

   It is a log MySql service layer

   • statement format, then is credited sql statement
   • row format will record the contents of the line , two in mind, before the update and after the update has.

   effect:

   Backup and restore data (you can specify a certain time to recover oh)

2. redo log (physical log)

   This is a log innodb engine. Why it is a physical log it, because it corresponds to the disk where data modification information, we modify the sql success is actually a redo log was written, then a thread and then flushed to the disk according to the redo log.

   • Each row record a modification

   • checking point. Check all the rows in front of the point is written to disk, and the line has not written to the disk arranged in a queue, then the queue head pointer is the checkpoint.

     We compare both logs above, such as the implementation of update T set c=c+1 where ID=2;the operation, as follows:

Note that the above written redolog, binlog achieve consistency, let the information is written in the prepare phase, two-phase commit .

1. undo log (rollback log)

To rollback, and to implement MVCC in innodb, the log is recorded in the data row

• In fact, each row of data in the database there are a few hidden fields , such as updating the transaction id of this line, a pointer to undo log line, whether the current mark is deleted and so on. This implementation is the use of a multi-version (different transactions) data coexist.

• Each row record on the record with information to modify the line? The list structure?

Second, the transaction isolation level

One of the four properties of transaction isolation, a transaction that is not visible to another transaction in the implementation process

1. Uncommitted Read
   • Dirty read occurs, a transaction read data from another uncommitted transactions
   • Consequently does not directly read the latest data memory
2. Read Committed
   • Occur non-repeatable read, read inconsistent transaction data
   • Not set a read lock , write lock is for the transaction, which is the end of a transaction does not release locks
   • Realization: MVCC, and will only read the latest version of the submitted data
3. Repeatable read
   • Still not set a read lock, lock there is a gap, that is, you can lock out the number of consecutive rows of data, the data can not be inserted on the inside, to avoid reading about magic
   • Realization: MVCC, only read the first data earlier than or equal to the current row of the transaction id (for rows marked for deletion, if its transaction id is greater than I, so I have not been deleted as this line)
   • Or will occur (before and after the read data read some of the magic number of rows inconsistent)
4. Serializable
   • Implementation: In the transaction level, reading and writing are mutually exclusive
   • Substantially prevents all the problems