1, generally speaking, it can be divided into MySQL Server storage engine layer and layer two sections
1.1, Server layer including connectors, query cache, analyzer, optimizer, actuators, etc., covering most of MySQL's core service functions, as well as all the built-in functions (such as date, time, and mathematical encryption function, etc.), across all storage engine functions are implemented in this layer, such as stored procedures, triggers, views,
1.2, storage engines layer is responsible for data storage and extraction. 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, Server layer - Connectors : Connectors responsible for establishing the connection with the client, access permissions, maintain and manage connections
2.1, a user after the connection is established, even if you use an administrator account on the user's permission has been modified, it will not affect the rights existing connections. After editing, then only the new connection will use the new permissions settings
2.2, after the completion of the connection, if you do not follow-up action, the connection is idle, you can see it in show processlist command. This figure is the result of the text show processlist, where the Command column reads "Sleep" in this line, it means there is now a free connection system
2.3, a client if no movement is too long, it will automatically connect disconnect. This time is controlled by the parameter wait_timeout, default is 8 hours; if, after the connection is disconnected, the client sends the request again, you will receive an error alert: Lost connection to MySQL server during query
2.4, the process of establishing a connection is often more complex, it is recommended that in use to minimize the act of establishing a connection, that is, try to use long connection; this is because the memory MySQL temporarily used during execution is to manage the connection object inside. These resources will be released only when disconnected. So if long connection accumulated, can lead to memory footprint is too large, the system is forced to kill (OOM), from Phenomenon is abnormal restart MySQL, consider the following two options to solve this problem
2.4.1, periodically disconnect the long connection . After a period of time, or a program executed which determines a large memory for queries, disconnect, then reconnect to query again.
2.4.2 If you are using MySQL version 5.7 or update can be executed after each of a relatively large operation to re-initialize the connection by performing mysql_reset_connection resources. This process does not require rewiring and re-do the verification authority, but the connection will be restored to the state when just finished creating.
3, Server layer - the query cache : After completing the connection is established, MySQL to get a query request, the query cache will first look is not performed before this statement. It was performed before the statement and its results may be key-value pairs to form, directly cached in memory. key statement is a query, value is the result of the query. If you can find the key query directly in the cache, then the value will be returned directly to the client
3.1, the implementation phase of the cache, it will continue to back the statement if not in the query. After the execution is completed, the results will be stored in the query cache. As you can see, if the query cache hit, MySQL does not need to perform complex operations later, you can return the results directly, this would be very efficient
3.2, but in most cases do not recommend using the query cache, query cache failure because very often, as long as there is an update to a table, all of this will be on the table query cache is emptied. It is likely that the results you struggling to keep up, not to use it, it was a full update emptied. Update pressure for large databases, the query cache hit rate is very low. Unless your business is to have a static table, it will be updated every time. For example, a system configuration table, query on this table that is suitable for use query cache
3.3, MySQL also provides such "on-demand" approach. Query_cache_type parameter can be set to DEMAND, so for the default SQL statement does not use the query cache. As for the statement you sure you want to use the query cache, you can use select SQL_CACHE * from T where ID = 10 explicitly specified
3.4, MySQL 8.0 version directly query cache entire function deleted
4, Server layer - Analyzer : if query cache does not hit, we should start to really execute the statement. First, MySQL need to know what you have to do, and therefore needs to be done to resolve SQL statements
5, Server layer - optimizer : After the analyzer, MySQL will know what you have to do up. Before you begin, but also to go through the process optimizer
Optimizer is there are multiple indexes on the table when deciding which index to use; or when a statement associated with multiple tables (join), decided to connect the various tables sequence
. 6, Server layer - actuator : optimizer phase is completed, the implementation of this program is established as a sentence, and then enters the actuator stage