1. Infrastructure: how a SQL query statement is executed?
In general, MySQL Server can be divided into two parts layer and the storage engine layer.
Server layer including connectors, query cache, analyzer, optimizer, actuators, etc., covering most of MySQL's core service functions, as well as all of the built-in functions (such as date, time, math and encryption functions, etc.), all cross-Storage Engine functions are implemented at this layer, such as stored procedures, triggers, and other views.
The storage engine layer is responsible for data storage and retrieval. Its architecture model is the plug-in, support for InnoDB, MyISAM, Memory, and other storage engine. Now the most commonly used storage engine InnoDB, MySQL 5.5.5 version of it from the beginning became the default storage engine.
2. Logging System: How to update a SQL statement is executed?
The query process is not the same, the update process also involves two important log module, the protagonist of which is exactly what we want to talk about today: redo log (redo logs) and binlog (archive log)
Specifically, when there is a record needs to be updated, InnoDB engine will first record written to redo log (pink sheet) inside, and updates the memory, this time the update is complete. At the same time, InnoDB engine at the appropriate time, this operation will update the record to disk inside, and this is often done to update the system more free time, it's like after closing the treasurer to do.
InnoDB redo log of fixed size, such as can be configured as a set of four files, each file is 1GB, then this "pink sheet" will be a total of 4GB of the recording operation. Written from scratch, it is written to the end back to the beginning of the write cycle, as shown in the following diagram.
Important log modules: binlog
Earlier we talked about, MySQL as a whole, in fact, there are two: one is the Server layer, which mainly do is MySQL functional level of things; there is an engine layer, responsible for specific storage-related issues. Above we talked to the pink plate redo log InnoDB engine is unique to the log, and Server layer has its own journal, called binlog (archive log)
both logs the following differences.
1.redo log InnoDB engine is unique; binlog is the MySQL Server layer implementation, all engines can be used.
2.redo log physical log record is "data on a page change has been made"; the binlog logical log records the original logic of the sentence, such as "field applied to ID = 2 c of the line 1 ".
3.redo log is written in circulation, fixed space will run out; binlog can append written. "Additional write" refers to the binlog file written to a certain size will switch to the next and does not overwrite the previous log.
3. Transaction Isolation: Why I can not see you changed?
Isolation and isolation level
mentioned transaction, you would certainly think ACID (Atomicity, Consistency, Isolation, Durability, namely atomicity, consistency, isolation, durability), today we are concerned that in which I, that is, "isolation sex. "
When there are multiple transactions simultaneously performed on the database, it may appear dirty read (dirty read), non-repeatable read (non-repeatable read), phantom read (phantom read) the problem in order to solve these problems, there is a " the concept of isolation level ".
Before talking about the isolation level, you must first know that you isolate the more tight, the lower the efficiency. So many times, we have to find a balance between the two. SQL standard transaction isolation level comprising: Uncommitted Read (read uncommitted), Read Committed (read committed), repeatable read (repeatable read) and serialized (serializable). Let me explain one by one for you:
1. read uncommitted means that a transaction has not submitted, it can be seen changes do other transactions.
2 Reading submission refers, after a transaction commits, it does change will be seen by other transactions.
3 repeatable read means, during the execution of a transaction to see the data, always with this transaction see when you start the data is consistent. Of course, under Repeatable Read isolation level, uncommitted change to other transactions is not visible.
4. serialization, as the name suggests is a record for the same line, "write" will add "write lock", "read" will be added "read lock." When the read-write lock conflict occurs, the transaction must wait before the visit of a completed transaction execution can not proceed.
We take a look at different isolation levels, transaction A which have different return results, but also is the figure inside V1, V2, V3 return value of what were yes.
+ If the isolation level is "read uncommitted", the V1 value is 2. This time transaction B, although not yet submitted, but the results have been seen A. Therefore, V2, V3 are also 2.
+ If the isolation level is "read committed", then 1 is V1, V2 is the value of 2. B's update transaction in order to be seen after submitting A. Therefore, the value of V3 is 2.
+ If the isolation level is "repeatable read", V1, V2 is 1, V3 is 2. The reason why V2 or 1, this requirement is followed by: data before and after the transaction during the execution of seeing must be consistent.
If the isolation level is + "serialized", then the process of "2 into 1" when the transaction will be locked in the B. A submission until after the transaction, the transaction B can continue. Therefore, from the point of view A, V1, V2 is a value 1, V3 is 2.