First, the storage engine
On our last festival comes, SQL execution plan is actuator assembly storage engine interface calls to complete.
Then we can be understood as: MySQL database management system relies on disk file storage engine and storage of data to interact.
MySQL storage engine So what has it?
There are MyISAM, InnoDB, Memory, and so on. And now the Internet, basically using the InnoDB storage engine, so then I will briefly summarize their learning about the InnoDB storage engine, relatively simple description of the components inside the InnoDB storage engine.
Second, the buffer pool
We now know that the data in the database is stored in a disk file.
So, every time we change search for additions and deletions to the table are directly in the disk file operation inside it?
The answer: No!
Because the performance of random read and write disk files is very poor, if all operations are carried out on disk, then there would be a high-performance MySQL statement, MySQL can not support high-concurrency, it would not be so in the Internet popular.
This time to introduce the most important components of the InnoDB storage engine, that is 缓冲池（Buffer Pool）, it is a very important memory structures. It is memory inside, with a very high performance read and write memory so that MySQL can support high concurrency.
Pool (Buffer Pool) using the principle:
Let's review process MySQL request was received.
①, MySQL monitor worker threads dedicated connection to the database connection pool, connection to get a connection in SQL statements.
②, then the SQL statement to SQL 接口to deal with, SQL interfaces will be carried out in the following series of processes.
③, 查询解析器will parse SQL statements into something MySQL can understand.
④, then 查询优化器to develop a set of best execution plan for a SQL statement.
⑤, 执行器it will go to storage engine interface calls executed according to plan.
The above article is a summary of the things, the storage engine interface to perform CRUD is how it? To update the operation as an example, the other the same way.
First, the storage engine update will first determine whether the SQL corresponding rows in the 缓冲池（Buffer Pool）inside. If the words directly in 缓冲池（Buffer Pool）updating the data in and then return; if not, the data is read from the disk file to 缓冲池（Buffer Pool）, and then update the operation, and then returns the result.
Three, undo log file
We all know that, in the transaction, until the transaction is rolled back submit updates to the data at any time. So what to do is to rely on it?
It relies on undo 日志文件.
Using the principles undo log file:
Update Data Example:
If you update a data row id = 100, the original column name "John Doe" to "John Doe", then the time will "id = 10" and "name = Joe Smith" the two key messages written undo 日志文件in.
When the transaction commits before you need to roll back from'll undo 日志文件find these keywords, and then roll back the update operation.
四、redo log buffer
When it comes to the above, all of the CRUD operations actually performed inside the pool, so in fact there is no modification of data and implement immediately to a disk file inside.
Then there is a problem: the dirty data buffer pool before the file back to disk brush, MySQL is down how to do?
At this point InnoDB storage engine provides a very important component, that redo log buffercomponent. It is also the memory of a buffer.
redo log buffer using the principle:
Or in the above updating operation as an example, when the data is updated, the data records key information is updated, the corresponding redo logs is then written redo log bufferin.
But there will still be a problem when it comes to the top, redo log bufferbut also in memory of. When that MySQL is down, since all data memory will be lost, so the pool of dirty data and redo log bufferlogs will still be lost.
This will result in a situation, the client receives a successful update of the information, but in the end the data inside the database is not updated successfully.
So, redo log bufferthere is a brush set strategy. Normally, when a transaction is committed, will be redo log bufferin the redo 日志brush back to the disk, so do not worry, the transaction commits successfully, but the data may be lost update problem. Even in 缓冲池（Buffer Pool）front of dirty data back to disk brush, MySQL is down, it will not lose data because the disk can be based on MySQL restart when the redo 日志update before restoring all dirty data.