MySQL EXPLAIN statement

For MySQL is in the implementation, EXPLAIN functionally DESCRIBE same. Practice, which is usually used to obtain information table, while the former used to demonstrate how MySQL can execute SQL statements ( Obtaining Execution Plan Information ).

DESCRIBE essentially SHOW COLUMNS abbreviated form of the statement.

EXPLAIN can act on these SQL keywords: SELECT, DELETE, INSERT, REPLACE, and UPDATE.
When used as a statement interpretability (explainable statement), which shows the implementation plan (execution plan) after the corresponding SQL statement is optimized, which is how MySQL will handle the query SQL statement, such as a JOINmulti-table when the statement is how to combine combined in what order.
As for FOR CONNECTION connection_idthe time instead of interpretability statement, showing that the implementation plan of the connection.
When it comes to query the partition table, EXPLAIN will be very useful.

By EXPLAIN you can see where to add indexes to speed up query optimization, you can also order whether the best time to view the linked table.

EXPLAIN outputted, generates a line in the results table for each participating in the search, the order of these is read by sequentially and the MySQL. MySQL is performed JOIN operation, it is actually done by nested loops, i.e., a first read the first record of the table, go to the second table to find a matching record, again matching the third table, and so on.

Wrokbench view the execution plan

MySQL GUI tools Workbench provides a visual way to view the execution plan, which is useful for performance analysis.

MySQL Workbench visual display in the execution plan

Meaning EXPLAIN output table

Column Name	Column names in JSON	meaning
id	select_id	SELECT id
select_type	N/A	SELECT type
table	table_name	Construction of the line output of the table name
partitions	partitions	To match the partition table
type	access_type	JOIN type
possible_keys	possible_keys	Optional index
key	key	Real selected index
key_len	key_length	Selected bond lengths are
ref	ref	And a column index for comparison
rows	rows	Estimated number of records for the query
filtered	filtered	The percentage is filtered out of the query record
Extra	N/A	Other additional information

From the MySQL Reference Manual on the table in the EXPLAIN output

JSON is a list of where the output is exported as the column name to use when JSON format.

Which select_typeSELECT type, all possible values in the table below:

select_type Value	JSON Name	Meaning
SIMPLE	None	A common type of SELECT, UNION and no sub-queries
PRIMARY	None	Outermost SELECT
UNION	None	When used with the second and subsequent SELECT UNION
DEPENDENT UNION	dependent (true)	The second and subsequent SELECT, because the outer query differ when used with UNION
UNION RESULT	union_result	UNION returned results
SUBQUERY	None	The first sub-query SELECT
DEPENDENT SUBQUERY	dependent (true)	The first sub-query SELECT, because the outer query varies
DERIVED	None	Derived table
DEPENDENT DERIVED	dependent (true)	Table depend on other tables derived
MATERIALIZED	materialized_from_subquery	Materialized subqueries
UNCACHEABLE SUBQUERY	cacheable (false)	You can not be cached sub-queries, re-run for the first row required
UNCACHEABLE UNION	cacheable (false)	Uncacheable subquery UNION in the second and subsequent SELECT

type JOIN type description how it is coupled, which have the following possible values, ordered from the most optimal time to:

System : only one record in the table, belonging const the JOIN type a special case.
const : Table at most only one matching record. Because there is only one, so remove the column values can be used as constants are optimized query fastest. When the main key (PRIMARY KEY) or a unique index (UNIQUE index) is compared with the constant use of this type.

SELECT * FROM tbl_name WHERE primary_key=1;

SELECT * FROM tbl_name
  WHERE primary_key_part1=1 AND primary_key_part2=2;

eq_ref : for the combination of the front of each record in the table, are read a record from the list. This type can be used to index columns using =operator for comparison.

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;

REF : For each combination of the foregoing records in the table, all reads all records matched to the index from the table. When using a non-ref for JOIN primary key or unique index column, or only key prefix scene.

SELECT * FROM ref_table WHERE key_column=expr;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;

FULLTEXT : JOIN using a FULLTEXT index type
ref_or_null : similar to ref, but will do additional queries NULL value. Optimization of this type are commonly used in JOIN subqueries, the following examples using MySQL Assembly table to deal with ref_or_null ref_table:

SELECT * FROM ref_table
  WHERE key_column=expr OR key_column IS NULL;

index_merge : said it will use the index merge optimization mode, see Section 8.2.1.3, "Index Merge Optimization" .
unique_subquery : Alternatively eq_ref type statement IN subquery some scenarios contingency tables.
index_subquery : Similar unique_subquery, alternatively IN subqueries, but acting in a non-unique index (nonunique indexes).

value IN (SELECT key_column FROM single_table WHERE some_expr)

Range : returns only the recording range.
index : the same type of ALL, but only use the index to search.
ALL : full table scan query.