type
status
date
slug
summary
tags
category
icon
password
AI summary
Last edited time
Mar 7, 2024 04:34 AM
explain 返回字段说明
Column | format=json JSON NAME | 说明 | 附加说明 |
id | select_id | The SELECT identifier | ㅤ |
select_type | ㅤ | The SELECT type | SIMPLE
PRIMARY
UNION
UNION RESULT
SUBQUERY
DEPENDENT SUBQUERY
DEPENDENT UNION
DERIVED
MATERIALIZED
UNCACHEABLE SUBQUERY
UNCACHEABLE UNION |
table | table_name | The table for the output row | ㅤ |
partitions | partitions | The matching partitions | ㅤ |
type | access_type | The join type | system->const->eq_ref->ref->range->index->all |
possible_keys | possible_keys | The possible indexes to choose | ㅤ |
key | key | The index actually chosen | ㅤ |
key_len | key_length | The length of the chosen key | 当 key_len 为 null 时, 说明没有使用到索引.
通过 key_len 计算规则, 可以判断索引字段的使用情况. |
ref | ref | The columns compared to the index | ㅤ |
rows | rows | Estimate of rows to be examined | ㅤ |
filtered | filtered | Percentage of rows filtered by table condition | ㅤ |
extra | ㅤ | Additional information | ㅤ |
id
The
SELECT identifier. This is the sequential number of the SELECT within the query. The value can be NULL if the row refers to the union result of other rows. In this case, the table column shows a value like <unionM,N> to indicate that the row refers to the union of the rows with id values of M and N.key_len 计算规则
- 可以为 null 的列 key 长度比 非 null 列 key 长度大 1;
- 如果索引列是字符型字段, 则索引列数据类型空间占用和字符集有关;
字符集 | 1个字符集占用字节数 |
gbk | 2 |
utf8 | 3 |
utf8mb4 | 4 |
latin1 | 1 |
- 如果索引列长度是变化的(比如varchar), 则在索引列数据类型本身占用空间的基础上再加 2;
select_type
he type of
SELECT, which can be any of those shown in the following table. A JSON-formatted EXPLAIN exposes the SELECT type as a property of a query_block, unless it is SIMPLE or PRIMARY. The JSON names (where applicable) are also shown in the table.select_type Value | JSON Name | Meaning |
SIMPLE | None | |
PRIMARY | None | Outermost SELECT |
None | ||
DEPENDENT UNION | dependent (true) | |
UNION RESULT | union_result | Result of a UNION. |
None | First SELECT in subquery | |
DEPENDENT SUBQUERY | dependent (true) | First SELECT in subquery, dependent on outer query |
DERIVED | None | Derived table |
DEPENDENT DERIVED | dependent (true) | Derived table dependent on another table |
MATERIALIZED | materialized_from_subquery | Materialized subquery |
UNCACHEABLE SUBQUERY | cacheable (false) | A subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query |
UNCACHEABLE UNION | cacheable (false) | The second or later select in a UNION that belongs to an uncacheable subquery (see UNCACHEABLE SUBQUERY) |
join types
system
The table has only one row (= system table). This is a special case of the
const join type.const
The table has at most one matching row, which is read at the start of the query. Because there is only one row, values from the column in this row can be regarded as constants by the rest of the optimizer.
const tables are very fast because they are read only once.const is used when you compare all parts of a PRIMARY KEY or UNIQUE index to constant values. In the following queries, tbl_name can be used as a const table:eq_ref
One row is read from this table for each combination of rows from the previous tables. Other than the
system and const types, this is the best possible join type. It is used when all parts of an index are used by the join and the index is a PRIMARY KEY or UNIQUE NOT NULL index.eq_ref can be used for indexed columns that are compared using the = operator. The comparison value can be a constant or an expression that uses columns from tables that are read before this table. In the following examples, MySQL can use an eq_ref join to process ref_table:ref
All rows with matching index values are read from this table for each combination of rows from the previous tables.
ref is used if the join uses only a leftmost prefix of the key or if the key is not a PRIMARY KEY or UNIQUE index (in other words, if the join cannot select a single row based on the key value). If the key that is used matches only a few rows, this is a good join type.ref can be used for indexed columns that are compared using the = or <=> operator. In the following examples, MySQL can use a ref join to process ref_table:fulltext
The join is performed using a
FULLTEXT index.ref or null
This join type is like
ref, but with the addition that MySQL does an extra search for rows that contain NULL values. This join type optimization is used most often in resolving subqueries. In the following examples, MySQL can use a ref_or_null join to process ref_table:index merge
This join type indicates that the Index Merge optimization is used. In this case, the
key column in the output row contains a list of indexes used, and key_len contains a list of the longest key parts for the indexes used.unique_subquery
This type replaces
eq_ref for some IN subqueries of the following form:index subquery
This join type is similar to
unique_subquery. It replaces IN subqueries, but it works for nonunique indexes in subqueries of the following form:range
Only rows that are in a given range are retrieved, using an index to select the rows. The
key column in the output row indicates which index is used. The key_len contains the longest key part that was used. The ref column is NULL for this type.range can be used when a key column is compared to a constant using any of the =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, LIKE, or IN() operators:index
The
index join type is the same as ALL, except that the index tree is scanned. This occurs two ways:- If the index is a covering index for the queries and can be used to satisfy all data required from the table, only the index tree is scanned. In this case, the
Extracolumn saysUsing index. An index-only scan usually is faster thanALLbecause the size of the index usually is smaller than the table data.
- A full table scan is performed using reads from the index to look up data rows in index order.
Uses indexdoes not appear in theExtracolumn.
MySQL can use this join type when the query uses only columns that are part of a single index.
ALL
A full table scan is done for each combination of rows from the previous tables. This is normally not good if the table is the first table not marked
const, and usually very bad in all other cases. Normally, you can avoid ALL by adding indexes that enable row retrieval from the table based on constant values or column values from earlier tables.