We must have written sql statements at work , and we will also optimize sql statements. We have read the corresponding explanations in optimizing sql statements. When optimizing sql statements, we must understand the meaning of each parameter in the execution plan and understand the execution. Sequence is of great help to SQL optimization.
1. View the execution plan through the Explain command
2. View the execution plan through Navicat
Execute the corresponding SQL statement in Navicat, and then click [Explain]. In fact, the execution plan is the SQL statement that explains how to execute it. Some versions have the "Explain" button above, and some versions have the "Explain" button below. See depending on the version
MySQL5.7 official website explanation
MySQL :: MySQL 5.7 Reference Manual :: 8.8.2 EXPLAIN Output Format
Table 8.1 EXPLAIN Output Columns
Column | JSON Name | Meaning |
---|---|---|
id | select_id |
The SELECT identifier |
select_type | None | The SELECT type |
table | table_name |
The table for the output row |
partitions | partitions |
The matching partitions |
type | access_type |
The join type |
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 |
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 | None | Additional information |
Note
JSON properties which are NULL
are not displayed in JSON-formatted EXPLAIN
output.
-
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, thetable
column shows a value like<union
to indicate that the row refers to the union of the rows withM
,N
>id
values ofM
andN
. -
The type of SELECT, which can be any of those shown in the following table. A JSON-formatted
EXPLAIN
exposes theSELECT
type as a property of aquery_block
, unless it isSIMPLE
orPRIMARY
. The JSON names (where applicable) are also shown in the table.select_type
ValueJSON Name Meaning SIMPLE
None Simple SELECT (not using UNION or subqueries) PRIMARY
None Outermost SELECT UNION None Second or later SELECT statement in a UNION DEPENDENT UNION
dependent
(true
)Second or later SELECT statement in a UNION, dependent on outer query UNION RESULT
union_result
Result of a UNION. SUBQUERY None First SELECT in subquery DEPENDENT SUBQUERY
dependent
(true
)First SELECT in subquery, dependent on outer query DERIVED
None Derived 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
)DEPENDENT
typically signifies the use of a correlated subquery. See Section 13.2.10.7, “Correlated Subqueries”.DEPENDENT SUBQUERY
evaluation differs fromUNCACHEABLE SUBQUERY
evaluation. ForDEPENDENT SUBQUERY
, the subquery is re-evaluated only once for each set of different values of the variables from its outer context. ForUNCACHEABLE SUBQUERY
, the subquery is re-evaluated for each row of the outer context.Cacheability of subqueries differs from caching of query results in the query cache (which is described in Section 8.10.3.1, “How the Query Cache Operates”). Subquery caching occurs during query execution, whereas the query cache is used to store results only after query execution finishes.
When you specify
FORMAT=JSON
withEXPLAIN
, the output has no single property directly equivalent toselect_type
; thequery_block
property corresponds to a givenSELECT
. Properties equivalent to most of theSELECT
subquery types just shown are available (an example beingmaterialized_from_subquery
forMATERIALIZED
), and are displayed when appropriate. There are no JSON equivalents forSIMPLE
orPRIMARY
.The
select_type
value for non-SELECT statements displays the statement type for affected tables. For example,select_type
isDELETE
for DELETE statements. -
The name of the table to which the row of output refers. This can also be one of the following values:
-
<union
: The row refers to the union of the rows withM
,N
>id
values ofM
andN
. -
<derived
: The row refers to the derived table result for the row with anN
>id
value ofN
. A derived table may result, for example, from a subquery in theFROM
clause. -
<subquery
: The row refers to the result of a materialized subquery for the row with anN
>id
value ofN
. See Section 8.2.2.2, “Optimizing Subqueries with Materialization”.
-
-
partitions
(JSON name:partitions
)The partitions from which records would be matched by the query. The value is
NULL
for nonpartitioned tables. See Section 22.3.5, “Obtaining Information About Partitions”. -
The join type. For descriptions of the different types, see EXPLAIN Join Types.
-
possible_keys
(JSON name:possible_keys
)The
possible_keys
column indicates the indexes from which MySQL can choose to find the rows in this table. Note that this column is totally independent of the order of the tables as displayed in the output from EXPLAIN. That means that some of the keys inpossible_keys
might not be usable in practice with the generated table order.If this column is
NULL
(or undefined in JSON-formatted output), there are no relevant indexes. In this case, you may be able to improve the performance of your query by examining theWHERE
clause to check whether it refers to some column or columns that would be suitable for indexing. If so, create an appropriate index and check the query with EXPLAIN again. See Section 13.1.8, “ALTER TABLE Statement”.To see what indexes a table has, use
SHOW INDEX FROM
.tbl_name
-
The
key
column indicates the key (index) that MySQL actually decided to use. If MySQL decides to use one of thepossible_keys
indexes to look up rows, that index is listed as the key value.It is possible for
key
to name an index that is not present in thepossible_keys
value. This can happen if none of thepossible_keys
indexes are suitable for looking up rows, but all the columns selected by the query are columns of some other index. That is, the named index covers the selected columns, so although it is not used to determine which rows to retrieve, an index scan is more efficient than a data row scan.For
InnoDB
, a secondary index might cover the selected columns even if the query also selects the primary key becauseInnoDB
stores the primary key value with each secondary index. Ifkey
isNULL
, MySQL found no index to use for executing the query more efficiently.To force MySQL to use or ignore an index listed in the
possible_keys
column, useFORCE INDEX
,USE INDEX
, orIGNORE INDEX
in your query. See Section 8.9.4, “Index Hints”.For
MyISAM
tables, running ANALYZE TABLE helps the optimizer choose better indexes. ForMyISAM
tables, myisamchk --analyze does the same. See Section 13.7.2.1, “ANALYZE TABLE Statement”, and Section 7.6, “MyISAM Table Maintenance and Crash Recovery”. -
key_len
(JSON name:key_length
)The
key_len
column indicates the length of the key that MySQL decided to use. The value ofkey_len
enables you to determine how many parts of a multiple-part key MySQL actually uses. If thekey
column saysNULL
, thekey_len
column also saysNULL
.Due to the key storage format, the key length is one greater for a column that can be
NULL
than for aNOT NULL
column. -
The
ref
column shows which columns or constants are compared to the index named in thekey
column to select rows from the table.If the value is
func
, the value used is the result of some function. To see which function, use SHOW WARNINGS following EXPLAIN to see the extended EXPLAIN output. The function might actually be an operator such as an arithmetic operator. -
The
rows
column indicates the number of rows MySQL believes it must examine to execute the query.For InnoDB tables, this number is an estimate, and may not always be exact.
-
filtered
(JSON name:filtered
)The
filtered
column indicates an estimated percentage of table rows filtered by the table condition. The maximum value is 100, which means no filtering of rows occurred. Values decreasing from 100 indicate increasing amounts of filtering.rows
shows the estimated number of rows examined androws
×filtered
shows the number of rows joined with the following table. For example, ifrows
is 1000 andfiltered
is 50.00 (50%), the number of rows to be joined with the following table is 1000 × 50% = 500. -
This column contains additional information about how MySQL resolves the query. For descriptions of the different values, see EXPLAIN Extra Information.
There is no single JSON property corresponding to the
Extra
column; however, values that can occur in this column are exposed as JSON properties, or as the text of themessage
property.
The type
column of EXPLAIN output describes how tables are joined. In JSON-formatted output, these are found as values of the access_type
property. The following list describes the join types, ordered from the best type to the worst:
-
The table has only one row (= system table). This is a special case of the const join type.
-
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
orUNIQUE
index to constant values. In the following queries,tbl_name
can be used as a const table:SELECT * FROM tbl_name WHERE primary_key=1; SELECT * FROM tbl_name WHERE primary_key_part1=1 AND primary_key_part2=2;
-
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
orUNIQUE 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 processref_table
: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;
-
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
orUNIQUE
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 processref_table
: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;
-
The join is performed using a
FULLTEXT
index. -
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 processref_table
:SELECT * FROM ref_table WHERE key_column=expr OR key_column IS NULL;
-
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, andkey_len
contains a list of the longest key parts for the indexes used. For more information, see Section 8.2.1.3, “Index Merge Optimization”. -
This type replaces eq_ref for some
IN
subqueries of the following form:value IN (SELECT primary_key FROM single_table WHERE some_expr)
unique_subquery is just an index lookup function that replaces the subquery completely for better efficiency.
-
This join type is similar to unique_subquery. It replaces
IN
subqueries, but it works for nonunique indexes in subqueries of the following form:value IN (SELECT key_column FROM single_table WHERE some_expr)
-
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. Thekey_len
contains the longest key part that was used. Theref
column isNULL
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:
SELECT * FROM tbl_name WHERE key_column = 10; SELECT * FROM tbl_name WHERE key_column BETWEEN 10 and 20; SELECT * FROM tbl_name WHERE key_column IN (10,20,30); SELECT * FROM tbl_name WHERE key_part1 = 10 AND key_part2 IN (10,20,30);
-
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
Extra
column saysUsing index
. An index-only scan usually is faster than ALL because 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 index
does not appear in theExtra
column.
MySQL can use this join type when the query uses only columns that are part of a single index.
-
-
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.
1. id: execution sequence
Divided into three situations: the id is the same; the id is not the same; the id has both the same and different ids
【1】If the ID is the same, the execution order is from top to bottom.
[2] If the id is different, the larger the id, the higher the level, and the order of execution will be the first;
[3] There are both the same and different IDs. Those with the same ID are in one group, and those with different IDs are in different groups. The larger the ID between different groups, the higher the level, the earlier they are executed. Between the same group, the execution order is from top to bottom
2. select_type: type of subquery
1. SIMPLE: A simple select query that does not contain subqueries or unions
2. PRIMARY: The query contains any complex subparts, and the outermost query is marked as primary
3. SUBQUERY: A subquery is included in the select or where list
4. DERIVED: The subqueries contained in the from list are marked as derived. MySQL executes these subqueries recursively and puts the results in a temporary table.
5. UNION: If the second select appears after union, it will be marked as union; if union is included in the subquery of the from clause, the outer select will be marked as derived.
6. UNION RESULT: Select to get the result from the union table
3. table: table name
4. type: type of query
From top to bottom, from poor to best, generally speaking, a good SQL query should reach at least the range level, and it is best to reach the ref
all: full table scan
Index : Traverse the index tree. The difference between index and ALL is that the index type only traverses the index tree. Although Index and ALL both read the entire table, index reads from the index, while ALL reads from the hard disk.
range : Index range scan, only retrieves a given range of rows, using an index to select rows. The key column shows which index is used. Generally, queries such as between, <, >, in, etc. appear in the where statement. Such range scans on indexed columns are better than full index scans. You only need to start at a certain point and end at another point, without scanning all indexes
ref : non-unique index scan, returns all rows matching a single value
eq_ref : unique index scan, for each index key, only one record in the table matches it
const, system : constant conversion
NULL: The statement is broken up and executed without even accessing tables or indexes
5、possible_keys
The query involves an index on the field, the index will be listed, but not necessarily actually used by the query
6、key
The index actually used by the SQL statement
7、key_len
The number of bytes of the index used indicates the number of bytes used in the index. The length of the index used in the query (the maximum possible length) is not the actual length used. In theory, the shorter the length, the better. key_len is calculated according to the table definition, not retrieved from the table
8、ref
Which columns or constants are used to look up values on indexed columns
9、rows
The number of rows needed to read to get the data
10、filtered
MySql5.7 official documentation describes it as follows:
Thefilteredcolumn indicates an estimated percentage of table rows filtered by the table condition. The maximum value is 100, which means no filtering of rows occurred. Values decreasing from 100 indicate increasing amounts of filtering.rowsshows the estimated number of rows examined androws×filteredshows the number of rows joined with the following table. For example, ifrowsis 1000 andfilteredis 50.00 (50%), the number of rows to be joined with the following table is 1000 × 50% = 500.
This text is not easy to understand. For example, there are explain results of the following three query statements. The filtered display for tables b and c is 100, while the display for table a is 18.
+-------------+-------+--------+---------+---------+------+----------+
| select_type | table | type | key | key_len | rows | filtered |
+-------------+-------+--------+---------+---------+------+----------+
| PRIMARY | a | range | search | 4 | 174 | 18.00 |
| PRIMARY | b | eq_ref | PRIMARY | 4 | 1 | 100.00 |
| PRIMARY | c | ALL | PRIMARY | 4 | 1 | 100.00 |
How can we understand the value of filtered? What conclusions can be drawn from the filtered values? Is 100 or 18 better?
First of all, filtered here represents the percentage of the final number of record rows obtained through the query conditions to the number of record rows searched through the search method specified by the type field.
Taking the first statement in the above figure as an example, MySQL first uses the index (the type here is range) to scan table a, and it is expected to get 174 records, which is the number of records displayed in the rows column. Next, MySql will use additional query conditions to perform secondary filtering on these 174 rows of records, and finally get 32 records that match the query statement, which is 18% of the 174 records. And 18% is the filtered value.
In a more perfect situation, an index should be used to directly search for 32 records and filter out the other 82% of the records.
Therefore, a relatively low filtered value indicates the need for a better index. If type=all, it means that 1000 records are obtained through a full table scan, and filtered=0.1%, which means that only 1 record meets the search conditions. At this time, if you add an index to directly search for a piece of data, then filtered can be increased to 100%.
It can be seen that filtered=100% is indeed better than 18%.
Of course, filtered is not a panacea. It is more important to pay attention to the values of other columns in the execution plan results and optimize the query. For example, in order to avoid filesort (using an index that can satisfy order by), even if the value of filtered is relatively low, there is no problem. Another example is the above scenario of filtered=0.1%. We should focus more on adding an index to improve query performance, rather than looking at the value of filtered.
11、Extra
other important information