This article is published by the official account [Developing Pigeon]! Welcome to follow! ! !
Old Rules-Sister Town House:
One. EXPLAIN statement
(I. Overview
After the MySQL query optimizer optimizes the query statement based on cost and rules, it will generate an execution plan that shows the specific way to execute the query, such as the order of multiple tables and the access method used by each table. The EXPLAIN statement allows us to query the specific execution plan of a certain query statement by adding an EXPLAIN directly before the specific query statement. Through the EXPLAIN statement, we can further think about how to improve our query statement.
(Two) EXPLAIN statement output field introduction
1. table
Each record output by the EXPLAIN statement corresponds to a single table access method, and the table column of each record represents the table name of the table.
2. id
The query statement generally starts with SELECT, and each SELECT keyword is assigned a unique id value. If there is only one SELECT in the connection query, the id values of the two records are the same. For sub-queries, there may be multiple SELECTs, and the ids of different records are different. It is also possible that the optimizer rewrites the sub-query into a join query, and the id becomes the same. For the UNION clause, each SELECT corresponds to an id value, but there is also a record id of NULL, because the function of the UNION clause is to aggregate the results of multiple queries and de-duplicate, and the temporary table will be used. The id of the table is NULL.
3. select_type
Each small query represented by the SELECT keyword defines an attribute named select_type, which represents the role of the small query in the entire large query.
（1） SIMPLE
Queries that do not include UNION or subqueries in the query statement are all counted as SIMPLE type, and join queries are also SIMPLE.
（2） PRIMARY
For large queries containing subqueries, the leftmost query is PRIMARY.
（3） UNION
For the large queries of UNION and UNION ALL, except for the small query on the far left, the remaining small queries are UNION.
（4） UNION RESULT
Use temporary tables to complete the deduplication of UNION queries. The temporary table is UNION RESULT.
（5） SUBQUERY
The query statement containing the subquery cannot be converted into the corresponding semi-join form, and the subquery is an unrelated query, and the optimizer adopts the subquery materialization scheme to execute. The query represented by the first SELECT of the subquery is SUBQUERY.
（6） DEPENDENT SUBQUERY
Same as above, except that the subquery is a correlated subquery.
（7） DEPENDENT UNION
In a large query containing UNION or UNION ALL, if each small query depends on the outer query, all subqueries except the leftmost one are DEPENDENT UNION.
（8） DERIVED
Contains the bad news of the derived table. If you query the derived table by materializing the derived table, the derived table corresponds to DERIVED.
（9） MATERIALIZED
After the subquery is materialized, it is connected to the outer query, and the subquery is MATERIALIZED.
4. type
The type list name is the access method for querying a certain table.
（1） system
When there is only one record in the table and the statistics of the storage engine used are accurate (MyISAM, MEMORY), then the access method of the table is system.
（2） const
When performing equivalence matching based on the primary key or unique secondary index listed in a constant, the access method to a single table is const.
（3） eq_ref
When performing a join query, if the driven table is accessed through the primary key or the unique secondary index column that does not allow the storage of NULL values, the access method for the driven table is eq_ref.
（4） ref
When performing equivalence matching with a constant through a normal secondary index column.
（5） ref_or_null
Equivalence matching is performed through the ordinary secondary index column in the constant, and the value of the index column can also be NULL.
（6） index_merge
Execute the query in the way of index merge.
（7） range
Use the index to get the records of certain single-point scan intervals, or get the records of certain range scan intervals.
（8） index
Use index coverage, but you need to scan all index records.
（9） ALL
Full table scan.
5. possible_keys 和 key
The indexes that may be used and the indexes that are actually used.
6. key_len
We hope to see directly from the execution plan what are the boundary conditions that form the scan interval, and the key_len column can tell us directly through calculations. The key_len value consists of three parts:
(1) The maximum storage space length occupied by the timing data of this column. If the column used to form the boundary condition of the scan interval is defined as VARCHAR(100) and the character set used is utf8, then a character corresponds to at most 3 bytes, Then the maximum byte length occupied by this column is 100 * 3 = 300
(2) If the column can store NULL values, add 1 byte
(3) For variable-length columns, there is 2 bytes of space to store the actual data of the column. The length of the storage space occupied by the actual data of the column. For
example, 303 can be judged to have a VARCHAR(100) column, and 606 can be judged There are two VARCHAR(100) columns.
7. ref
The ref column shows what is equivalent to the index column, such as a constant const or a certain column.
8. rows
When the query optimizer chooses to use a full table scan query, the rows column represents the estimated number of rows in the table;
If you use an index query, the rows column represents the number of index records expected to be scanned;
9. filtered
This column represents what percentage of the records that the query optimizer predicts will satisfy the rest of the search conditions. This column is meaningless for single-table queries. It is more concerned with the filtered value that drives the table in the join query.
(3) Execution plan in Json format
The important attribute of cost is missing from the EXPLAIN statement just seen. We can query the cost by looking at the execution plan in Json format. Just add FORMAT=JSON between EXPLAIN and the real query statement.
The cost is in cost_info:
read_cost = I/O cost + CPU cost for detecting rows * (1-filter) records
eval_cost = the cost of detecting rows * filter records
prefix_cost = read_cost + eval_cost (for single table query)
For multi-table queries, prefix_cost is not equal to read_cost and eval_cost, because it may be accessed multiple times. In short, remember that prefix_cost is the entire cost, whether it is a single-table query or a join query.