You don't know the explain command yet?
1. The explain command
1.1 Experience the explain command
First, let's experience how explainthe command is used and what the output is:
explain select * from table_user ;Output result:
I found that it is very easy to use, as long as explain is followed by SQL statements and it is done (in versions before MySQL 5.6, only interpreted SELECTstatements are allowed, and since MySQL 5.6, non- SELECTstatements can also be interpreted).
1.2 Why do you need the explain command
Many times when we finish writing an SQL statement, we often want to know whether the SQL statement is executed efficiently. In other words, whether the index we have built is used in this SQL statement, we can use the explaincommand to analyze it! To put it simply: through the explaincommand we can learn how the SQL is executed, and then parsing the result of the explain can help us use a better index and finally optimize it! Through the explaincommand, we can know the following information: the read order of the table, the type of data read operation, which indexes can be used, which indexes are actually used, references between tables, how many rows in each table are queried by the optimizer, etc. .
1.3 Read the explain command result
The output of the explain command has 10 columns:id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra
1.3.1id
id contains a set of numbers representing the order in which the SELECT clause or table of operations in the query is executed .
There are also several cases on the id column:
If the id is the same, the execution order is from top to bottom.
If the ids are not the same, the serial number of the id will be incremented. The larger the id value, the higher the priority and the first to be executed. (Generally, the id of the SQL statement with subquery will be different)
1.3.2select_type
Indicates the type of the select query. There are several types under the select_type attribute:
SIMPLLE : Simple query that does not contain UNION or subqueries
PRIMARY : If the query contains UNION or subqueries, the outermost query is identified as PRIMARY
UNION: Indicates that this query is the second or subsequent query in UNION
DEPENDENT: UNION satisfies the second or subsequent query in UNION, second depends on the query outside
UNION RESULT: The result of the UNION
SUBQUERY : The first select statement in a subquery (the subquery is not in the from clause)
DEPENDENT SUBQUERY: The first select in a subquery, while depending on the outer query
DERIVED : Subqueries included in the from clause (also known as derived tables)
UNCACHEABLE SUBQUERY: Satisfy is the first select statement in the subquery, and means that some feature in the select prevents the results from being cached in an Item_cache
UNCACHEABLE UNION: Satisfies that this query is the second or subsequent query in UNION, and means that some feature in select prevents results from being cached in an Item_cache
1.3.3table
This column shows which table the corresponding row is accessing (aliases are displayed if there are aliases).
When there is a subquery in the from clause, the table column is in the <derivenN>format , indicating the query that the current query depends on id=N, so id=Nthe
1.3.4type
This column is called the association type or access type , which indicates how MySQL decides to find qualified rows in the table, and is also an important basis for us to judge whether the query is efficient .
The following are common values
ALL: Full table scan , this type is one of the worst performing queries. Generally speaking, our query should not appear ALL type, because such a query, in the case of the largest amount of data, is a huge disaster to the performance of the database.
index: full index scan , similar to ALL type, except that ALL type is a full table scan, while the index type scans all indexes. The main advantage is that sorting is avoided, but the overhead is still very large. If you see Using index in the Extra column, it means that a covering index is being used, which only scans the indexed data, which is much less expensive than a full table scan in index order.
range: A range scan is a limited index scan that starts at a certain point in the index and returns rows that match this range. This type usually appears in
=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN、IN()the operation of . The key column shows which index is used. When the type is this value, the output ref column is NULL, and the key_len column is the one with the longest index used in this query.ref: An indexed access, also called an indexed lookup, that returns all rows matching a single value. This type usually occurs in join queries of multiple tables, for non-unique or non-primary key indexes, or for queries that use leftmost prefix rule indexes.
eq_ref: Use this index lookup to return at most one matching record. This value occurs when using a unique index or primary key lookup and is very efficient.
const, system: The table has at most one matching row, read at the start of the query, or the table is a system table and only one row matches. Where const is used in the case of a fixed value comparison with the primary key or unique index.
NULL: No access to the table is required during the execution phase.
1.3.5possible_keys
This column shows which indexes the query might use to find
1.3.6key
This column shows the index that MySQL actually decided to use. If no index is selected, the key is NULL.
1.3.7key_len
This column shows the number of bytes used in the index. When the value of the key column is NULL, the column is also NULL
1.3.8ref
This column shows which fields or constants are used in conjunction with the key to query records from the table.
1.3.9rows
This column shows the estimated number of rows to be read to find the desired row. This value is an estimate, and in principle, the smaller the better.
1.3.10extra
other information
Common values are as follows:
Using index : Using a covering index means that the required data can be found by querying the index without scanning the table data file, which often means that the performance is good.
Using Where: Filters are performed after the storage engine retrieves rows, using where clauses to limit which rows will be matched to the next table or returned to the user.
Using temporary: A temporary table will be used when sorting query results, which generally occurs in sorting, grouping, and multi-table joins. The query efficiency is not high, and optimization is recommended.
Using filesort: Use an external index to sort the results instead of reading rows from the table in index order. Generally, if this value occurs, it is recommended to optimize and remove it, because such a query consumes a lot of CPU resources.
Original link