MySQL Server is divided into layers and layers in the overall storage engine architecture. Wherein Server layer comprising a connector, the query cache, the analyzer, optimizer, executor and the like, stored procedures, triggers, views, and built-in functions are implemented in this layer. Engine layer is responsible for data storage and retrieval of data, such as InnoDB, MyISAM, Memory and other engines. After the client connects to the Server layer, Server will call interface provides data engine, changed data.
Connector
And the client is responsible for establishing a connection, access and management of user rights and to maintain the connection.
By show processlist;the state to query the connection. After the user establishes a connection, even if the administrator to change the user's permission to connect, it will not affect connected users. Length of 8 hours default connection, over time will be disconnected after.
Simply put under long connection:
Advantages: In connection time, the client has been using the same connection, multiple connections to avoid resource consumption.
Disadvantages: When MySQL execution, using the memory connected object management, due to the long time has not been released, will cause the system memory overflow, so the need for regular system kill off a long connection, or after performing large queries, disconnect. MySQL 5.7, you can mysql_rest_connectionconnect resource initialization, or even do not need to re-verify permission.
Query Cache
When receiving the query request, will now query cache queries (key / value preservation), whether or not enforced. If not, walk the normal flow of execution.
But in reality, the query cache is generally no need to set. Because when it comes to the look-up table is updated, the cache will be cleared. So for static tables. After MySQL8.0, the query cache is repealed.
Analyzer
lexical analysis:
The identification select, table name, column name, and the like to determine whether it is present.
Parsing:
Determine whether the statement MySQL syntax.
Optimizer
Determine the index, join order join tables, which are selected optimization scheme.
Actuator
Before the implementation of specific statements, you will first check permissions, using an interface provided by the data engine through query. If you set a slow query, you will see the corresponding log rows_examinedto indicate the number of lines scanned. In some scenarios (index), the actuator called once, but a number of scan lines in the data engine, the engine scans the rows and rows_examined not identical.
The reason without prior inspection authority: triggers such as is the case, you need to determine permissions actuator stage, can not verify the optimizer stage.
MySQL log module
As previously mentioned, MySQL Server and data into the entire engine layer, and each also corresponds to its own log files. If using the InnoDB engine, corresponding to the redo log file. Server layer corresponds to the binlog files. As for why there is two logging system, you look down.
redo log
InnoDB redo log is unique log, redo log Why introduce it, to imagine such a scenario, MySQL in order to ensure persistence is required to write data to a disk file. We know that, when written to disk, the file will be IO, the search operation, if the operations are updated every time so, overall efficiency is particularly low, simply can not use.
Since not written directly to disk, the solution is first written into the memory, and then update the disk when the system is idle to it. Optical memory but not update, if abnormal system downtime and restart the data in memory is not written to disk will be lost, data consistency issues emerged. Then redo log on to play a role in the update operation occurs, InnoDb will first write redo log log (record the data has changed how kind), and then update the memory and then written to disk at the appropriate time. First write the log, (Write-Ahead- Logging) technology in the disk write operation, which is often when it comes to the WAL.
Appears redo log, in addition to have a great improvement in efficiency, but also to ensure that MySQL has the ability to crash-safe in case an exception occurs, no data is lost.
In the specific implementation of the redo log size is fixed, may be configured as a set of four files, each file 1GB, an update to a four cycle write file.
write pos recording current write position on finished after the shift, when the first end of the first written document 4, rewritten from the 0th position.
check point indicates the position of the current that can be erased when the update data to the disk, check point is moved rearwardly.
And write pos position between the check point, is the ability to update the record operation of the space. When the write pos catch check point, can not perform the new operation, let some of the data written to the check point.
Can be innodb_flush_log_at_trx_commitset to 1, the ability to open redo log persisted.
binlog
Server log binlog layer is mainly used for archiving, backup, synchronize standby, play a role in restoring the data, a common log format row, mixed, statementthree. Use of specific methods can be found in Binlog this recovery log.
Can sync_binlogopen binlog = 1 is written to disk.
The distinction here binlog and redo:
- Different owners, binlog is Server layer, all engines can be used. InnoDB redo log is unique.
- Different types, the binlog logical log records the original logical statements (specific statement). redo log is a physical log records in a data page is made what changes.
- Different ways of writing data, binog log has been added, and redo log is written circulation.
- Different functions, binlog for archiving and redo log is used to ensure crash-safe.
Two-phase commit
An update statement, the update process in the InnoDB engine is as follows. After updating the memory, writes redolog and written binlog put together into a transaction with redo log and write the last binlog process is often said that the two-phase commit. To ensure that when an accident occurs, the data consistency.
Here assumption, what if two-phase commit will not happen?
- After the first to write redo log write binlog. Assumed that after writing redo log, MySQL abnormal restart has occurred and the binlog not written. After the restart, because the redolog has been written, then the contents of the database is not a problem. But this time, if you want to take binlog backup or restore, will find less last update logic, resulting in inconsistent data.
- The first to write binlog and redo log. After binlog write, MySQL abnormal restart, redo log is not written. At this point after the restart and found redo log write was not successful, the transaction invalid task, but this time was more than a binlog update statement after take to restore the natural data is inconsistent.
Re-analysis of the two-phase commit:
- Ben collapse write redo log prepare phase, after the restart and found redo log did not write, find the transaction.
- If Ben collapse when writing binlog, restart, found binlog is not written, a rollback operation
- If the crash after writing redo log and binlog, after the restart and found not to submit, it proceeds commit.
Section
In the beginning of the article, we describe the overall architecture is divided into MySQL Server engine layer and layer, and a brief description of the execution of a statement. Then MySQL InnoDB as the default engine, because more than the native MyISAM transactions and the ability to crash-safe after 5.5 selection.
The crash-safe is achieved by the redo log. And redo log similar to the log file as well as binlog, Server is the engine of logs for archiving and backing up data.
The last-mentioned, in order to ensure data consistency, the redo log and binlog into the same transaction, the two-phase commit operation is often mentioned.