MySQL Performance artifact Explain

This article relates: MySQL performance optimization of the use of artifacts Explain

Brief introduction

Although not able to immediately use Explain tune our SQL, it can not give us some adjustment proposals, but it allows us to understand how to optimize MySQL is executing SQL statements

By Explain, we can analyze the following results:

Reading order table
Data read operation type of operation
Which indexes can be used
Which indexes are actually used
References between tables
Each table of how many rows the query optimizer

Explain command usage is very simple, plus Explain before the select statement can be, for example:

1	explain select * from user ;

It results mainly contains the following fields
id, select_type, table, partitions, type, possible_keys, key, ref, rows, filtered, extra
Next we look at the meaning of each field

id Query serial number

Loading sequence table

join query loading order of the tables are the same, so both 1

When contain sub-queries, perform sub-queries, so maximum user id value table

select_type query type

Common values are:

SIMPLE: simply select the query, and the query does not contain sub-index
PRIMARY: If the query contains any sub-query, the outermost query was recorded as PRIMARY
SUBQUERY: contains a subquery in the SELECT list or WHERE
DERIVED: FROM subquery contained in the list is marked DERIVED (derivative), MySQL will recursively these sub-queries, the results in a temporary table
UNION: If after the second SELECT appear in the index, were labeled UNION: If the index is included in the FROM clause of a query, the outer layer is labeled SELECT: DERIVED
UNION RESULT: get results from the index table query

table lookup table or derived tables involved

type query type

By type field, we can determine the inquiry is a full table scan or index scan, type commonly used values are:

system: only one data table
const: for the equivalent query scans a primary key or unique index, simple to understand once you get to read the data, for example, the following query primary key index
eq_ref: unique index scan, for each index key, only one record in the table match. Common in the primary key or unique index scan
ref: non-unique index scanning, returns all rows matching a separate value
range: query indication index range, e.g. =, <>,>,> =, <, <=, IS, NULL, <=>, BETWEEN, IN, etc.
index: the data to be queried directly in the index tree can be obtained, without the need to scan data, such as:
ALL: represents the full table scan, this is the worst type of query performance query

Comparison of the performance of type TYPE
Generally speaking, the different types of performance type relationship is as follows:
ALL <index <Range <REF <eq_ref <const <System

The index can be used to query when possible_keys.

possible_keys expressed in MySQL query can use the index. Note that not necessarily use, actual use is determined by the key field

key index used by the query

This field is in the current MySQL query to actually use the index.

Using the index number of bytes key_len

This field can be assessed composite index is fully used, or only the leftmost part of the field is used to.

To find the estimated number of rows MySQL result set to read rows of data need to be scanned

Extra extra information

There are several common elements:

Using filesort: MySQL additional sorting operation can not be sorted by index order to achieve the effect of generally Using filesort, have suggested optimization removed, because such a query large CPU resource consumption.
Using index: indicates that the query can find the data in the index tree without scanning the table data file, often illustrate good performance
Using temporary: there are queries using temporary tables, usually appears in the case of sorting, grouping, and multi-table join, the query efficiency is not high, the proposed optimization.
Using where: that the use of a filter where
Using join buffer: that the use of the connection cache, for example, at the time of the query, the number of very large multi-table join, then the buffer configuration file join buffer transfer large number of
impossible where: where clause is always false, can not be used to obtain any tuple
select tables optimized away: Under no circumstances GROUPBY clause, based on the index optimization MIN / MAX operation or for MyISAM storage engine optimization COUNT (*) operation, without waiting for the implementation phase and then calculated, generated query execution plan optimization phase is complete
distinct: Optimization of distinct operations, the first matching tuple is found after stopping the operation to find the same value

All blog article first appeared in public No. "Java learning record" reproduced leave
scan code number to receive public attention 2000GJava Learning Resources