EXPLAIN command details

Information contained in the execution plan

+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+

MySQL execution plan calling method
1.EXPLAIN SELECT ...... Variation:
2.EXPLAIN EXTENDED SELECT ......
"decompile" the execution plan into a SELECT statement, run SHOW WARNINGS, you can get the query statement optimized by the MySQL optimizer
3.EXPLAIN PARTITIONS SELECT ...... EXPLAIN for partition table generates QEP information

Information interpretation

id

1. id: Contains a set of numbers that represent the order in which the select clause or operation table is executed in the query

  • The id is the same, and the execution order is from top to bottom;
  • If it is a subquery, the serial number of the id will be incremented. The larger the id value, the higher the priority and the first to be executed;
  • If the id is the same, it is considered to be a group and executed in order from top to bottom; in all groups, the larger the id value, the higher the priority, and the earlier the execution;
select_type

2. select_type The type of each select clause in the query (simple OR complex)

a. SIMPLE: The query does not contain sub-queries or UNION
b. If the query contains any complex sub-parts, the outermost query is marked as: PRIMARY
c. In the SELECT or WHERE list contains sub-queries, the sub-query is marked as: SUBQUERY
d. The subquery contained in the FROM list is marked as: DERIVED (derived) used to represent the select of the subquery contained in the from clause, mysql will recursively execute and put the result into a temporary table middle. Internally the server is called a "derived table" because the temporary table is derived from a subquery
e. If the second SELECT occurs after a UNION, it is marked as UNION; if UNION is included in a subquery of the FROM clause , the outer SELECT will be marked as: DERIVED
f. The SELECT that gets the result from the UNION table is marked as: UNION RESULT

SUBQUERY and UNION can also be marked as DEPENDENT and UNCACHEABLE.
DEPENDENT means that select depends on the data found in the outer query.
UNCACHEABLE means that some feature in select prevents results from being cached in an item_cache.

type

3. type                                       

Indicates how MySQL finds the desired row in the table, also known as "access type", common types are as follows:

 ALL, index, range, ref, eq_ref, const, system, NULL Left to right, worst to best performance

a. ALL: Full Table Scan, MySQL will traverse the full table to find matching rows;

b. index: Full Index Scan, the difference between index and ALL is that the index type only traverses the index tree;

c. range: index range scan, the scan of the index starts at a certain point, and returns the rows that match the range. Obvious index range scans are queries with between or where clauses with <, >. When mysql uses an index to find a series of values, such as IN() and OR lists, it will also display a range (range scan), of course, there are differences in performance;

d. ref: Use a non-unique index scan or a prefix scan of a unique index to return rows that match a single value;

e. eq_ref: Similar to ref, the difference is that the index used is a unique index. For each index key value, there is only one record in the table that matches. In short, the primary key or unique key is used as the association condition in the multi-table connection;

f. const, system: When MySQL optimizes a certain part of the query and converts it to a constant, use these types of access. If the primary key is placed in the where list, MySQL can convert the query to a constant;

Note: system is a special case of const type. When the query table has only one row, use system

g. NULL: MySQL decomposes the statement during the optimization process, and does not even need to access the table or index during execution. For example, selecting the minimum value from an index column can be done through a separate index lookup.

 possible_keys

4. possible_keys
indicates which index MySQL can use to find records in the table. If there is an index on the field involved in the query, the index will be listed, but not necessarily used by the query

key

5. The key
shows the index actually used by MySQL in the query. If no index is used, it is displayed as NULL

key_len

6. key_len
represents the number of bytes used in the index, and the length of the index used in the query can be calculated through this column (the value displayed by key_len is the maximum possible length of the index field, not the actual length, that is, key_len is calculated according to the table definition. obtained, not retrieved from the table)

ref

7. ref
indicates the connection matching condition of the above table, that is, which columns or constants are used to find the value on the index column

rows

8. rows
indicates the number of rows that MySQL estimates to read to find the
required

Extra

9. Extra
contains extra information that is not suitable for display in other columns but is very important

a. Using index
This value indicates that a Covering Index is used in the corresponding select operation

Covering Index (Covering Index)
MySQL can use the index to return the fields in the select list without having to read the data file again according to the index. The index that
contains all the data that meets the query needs is called a covering index (Covering Index)
. , be sure to take out only the required columns in the select list, not select *, because if all fields are indexed together, the index file will be too large and the query performance will be degraded;

b. Using where
indicates that the mysql server will filter the rows after the storage engine retrieves them. Many where conditions involve columns in the index that can be checked by the storage engine when (and if) it reads the index, so not all queries with where clauses will show "Using where". Sometimes the presence of "Using where" is a hint that the query could benefit from a different index.

c. Using temporary
indicates that MySQL needs to use a temporary table to store the result set, which is common in sorting and grouping queries

This value indicates that an internal temporary (memory-based) table is used. A query may use multiple temporary tables. There are many reasons why MySQL can create temporary tables during query execution. Two common reasons are using DISTINCT on different tables, or using different ORDER BY and GROUP BY columns. You can force a temporary table to use the disk-based MyISAM storage engine. There are two main reasons for this:
1) The space occupied by the internal temporary table exceeds the limit of the min(tmp_table_size, max_heap_table_size) system variable
2) TEXT/BLOB columns are used

d. Using filesort
The sorting operation in MySQL that cannot be done with an index is called "file sorting"

e. Using join buffer
changed the value to emphasize that the index is not used when obtaining the join condition, and the join buffer is required to store the intermediate results. If this value is present, it should be noted that depending on the specifics of the query, an index may need to be added to improve performance.

f. Impossible where
This value emphasizes that the where statement will result in no eligible rows.

h. Select tables optimized away
This value means that the optimizer may only return one row from the aggregate function result by using the index only.

I. Index merges
When MySQL decides to use more than one index on a given table, one of the following formats will appear, detailing the index used and the type of merge.
Using sort_union(...)
Using union(...)
Using intersect(...)

 

Summary:
• EXPLAIN does not tell you about triggers, stored procedures or the impact of user-defined functions on the query
• EXPLAIN does not consider various caches
• EXPLAIN does not show the optimization work done by MySQL when executing the query
• Partial statistics It is an estimate, not an exact value
. EXPALIN can only explain the SELECT operation, other operations should be rewritten as SELECT to view the execution plan

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325483846&siteId=291194637