Explanation of each column output by explain statement

# EXPLAIN Statement output column interpretation

Name	describe
id	In a large query statement, each SELECT Each keyword corresponds to a unique id
select_type	SELECT The type of query corresponding to the keyword
table	Table name
partitions	Matching partition information
type	Access methods for single tables
possible_keys	Possible indexes
key	Index actually used
key_len	The actual index length used
ref	When using index column equivalent queries , Information about the object matching the index column
rows	Estimated number of records to read
filtered	The percentage of records remaining after a table is filtered by search criteria
Extra	Some extra information

# select_type

every last SELECT The small queries represented by keywords have a definition called select_type Properties of , It means we As long as you know about a small query select_type attribute , You know what role this small query plays in the whole big query

# SIMPLE

The query statement does not contain UNION Or subquery queries are counted as SIMPLE type , Join query is also SIMPLE type .

# PRIMARY

To contain UNION 、 UNION ALL Or for a large subquery , It's made up of a few small queries , The leftmost query Of select_type The value is PRIMARY

# UNION

To contain UNION perhaps UNION ALL For big queries , It's made up of a few small queries , Except for the little query on the left Outside , The rest of the small queries are select_type The value is UNION

# UNION RESULT

MySQL Choose to use a temporary table to complete UNION Query de duplication work , For the query of the temporary table select_type Namely UNION RESULT , The example above has , I won't go into that .

# SUBQUERY

If the query statement containing the subquery cannot be converted to the corresponding semi-join In the form of , And the subquery is an unrelated subquery , And the query optimizer decides to use the sub query

Query materialized scheme to execute this sub query , The first... Of the subquery SELECT The query represented by the keyword select_type Namely SUBQUERY

# DEPENDENT SUBQUERY

If the query statement containing the subquery cannot be converted to the corresponding semi-join In the form of , And the subquery is a related subquery , Then this sub query One of the first SELECT The query represented by the keyword select_type Namely DEPENDENT SUBQUERY

# DEPENDENT UNION

Include in UNION perhaps UNION ALL In the big query , If each small query depends on the outer query , Except for the little query on the far left , The rest of the small queries are select_type The value is DEPENDENT UNION

# DERIVED

For queries containing derived tables that are materialized , The derived table corresponds to the select_type Namely DERIVED

# MATERIALIZED

When the query optimizer executes a statement that contains subqueries , Select materialize the sub query and connect it with the outer query , Corresponding to this subquery select_type The attribute is MATERIALIZED

# UNCACHEABLE SUBQUERY

Not commonly used , Don't nag more .

# UNCACHEABLE UNION

Not commonly used , Don't nag more .

# type

A record of the implementation plan represents MySQL Access method when executing query on a table

system： When there is only one record in the table and the statistics of the storage engine used by the table are accurate , such as MyISAM、Memory, So the way to access the table is system.

const： Match constants by primary key or unique secondary index column

eq_ref： When connecting queries , If Driven tables are accessed by matching primary keys or unique secondary index columns Of （ If the primary key or unique secondary index is a federated index , All index columns must be compared for equivalence ）, Then it's right to Access method of driven table Namely eq_ref

ref： The search condition is that the secondary index column is compared with the constant equivalence Locate multiple records , An access method that uses secondary indexes to execute queries

fulltext Full-text index

ref_or_null： When performing an equivalent matching query on a common secondary index , The value of the index column can also be NULL When the value of , Then the access method to the table might be ref_or_null

index_merge： In general, only one index can be used for a table query , However, when we nag about the single table access method, we specially emphasize that it can be used in some scenarios Intersection 、 Union 、 Sort-Union These three indexes are combined And execute the query , Multiple indexes will be used .

unique_subquery： Be similar to Of the driven table in a two table connection eq_ref Access method , unique_subquery yes For some include IN Subquery In the query statement of , If the query optimizer decides to IN The subquery is converted to EXISTS Subquery , and Subqueries can use the primary key for equivalent matching Words , Then the subquery execution plan is type The value of the column is unique_subquery

index_subquery： index_subquery And unique_subquery similar , The only way to access the tables in the subquery is to use Ordinary index （unique_subquery Previously, the primary key index or primary and secondary indexes were used ）.

range： If you use an index to get some Range interval The record of , Then it's possible to use range Access method

index： When we can use index overlay , But when you need to scan all index records , The access method of this table is index.

ALL： Full table scan .

# possible_keys and key

possible_keys The list is shown in a query statement , What are the indexes that may be used to perform a single table query on a table , key The list shows which indexes are actually used .

# key_len

key_len The list shows when the optimizer decides to execute a query using an index , The maximum length of the index record , It consists of these three parts ：

• For index columns with fixed length types , The maximum length of the storage space actually occupied by it is the fixed value , For variable length index columns of the specified character set , For example, the type of an index column is VARCHAR(100) , The character set used is utf8 , Then the maximum storage space actually occupied by this column is 100 × 3 = 300 Bytes .
• If the index column is used to store NULL value , be key_len Can't store NULL When the value is more 1 Bytes .
• For variable length fields , There will be 2 A space of bytes to store the actual length of the variable length column .

Example

Tips ： Some students may have questions ： You nag ahead InnoDB Line format does not mean , It is not possible to store the actual length of the variable length field 1 Bytes or 2 Byte? ？ Why now

No matter three, seven, twenty-one are used 2 Bytes ？ The point to be emphasized here is , The execution plan is generated in MySQL server Functions in the layer , It is not specific to the functions of a specific storage engine , Design

MySQL My uncle outputs... In the execution plan key_len Column The main purpose is to distinguish the specific index columns used in a query using a joint index , It is not for the sake of accurate explanation

The storage engine stores the actual length of the variable length field. What space does it occupy 1 Two bytes or 2 Bytes

# ref

# rows

If the query optimizer decides to perform a query on a table using a full table scan , Implementation plan rows The column represents the expected number of rows to scan , If an index is used to execute a query , Implementation plan rows The column represents the number of index record rows to be scanned

# filtered

When analyzing the cost of connection query, I put forward a condition filtering The concept of , Namely MySQL A strategy used when calculating the fan out of the driving table ：

• If you use a single table query executed by full table scanning , When calculating the fan out of the drive table, you need to estimate how many records meet the search conditions .
• If an index is used, perform a single table scan , When calculating the fan out of the driving table, you need to estimate how many records meet the search conditions other than the search conditions of the corresponding index .

Connect the execution plan records corresponding to the drive table in the query filtered value , For example, the following query ：

You can see from the execution plan , The query optimizer intends to s1 As a driver table , s2 As driven tables . We can see the driver table s1 The execution plan of the table rows As a 9688 , filtered As a 10.00 , That means driving tables s1 The fan out value of is 9688 × 10.00% = 968.8 , This means that we have to perform about 968 Queries .

Extra Columns are used to illustrate some additional information , We can use this additional information to understand more accurately MySQL How the given query statement will be executed

Welcome to your attention ggball Blog ！