MySQL Explain in detail

In our daily work, we will sometimes open slow queries to record some SQL statements that have been executed for a long time. Finding these SQL statements does not mean that the work is over. Sometimes we often use the explain command to view one of these SQL statements. You can check whether the SQL statement has used an index and whether a full table scan has been performed. You can use the explain command to check. So we dig deeper into MySQL's cost-based optimizer, and also get a lot of details about the access strategies that may be taken into account by the optimizer, and which strategy is expected to be adopted by the optimizer when running the SQL statement. (QEP: sql generates an execution plan query Execution plan)

copy code
mysql> explain select * from servers;
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
| id | select_type | table   | type | possible_keys | key  | key_len | ref  | rows | Extra |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
|  1 | SIMPLE      | servers | ALL  | NULL          | NULL | NULL    | NULL |    1 | NULL  |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
1 row in set (0.03 sec)
copy code

The information from expain has 10 columns, namely id, select_type, table, type, possible_keys, key, key_len, ref, rows, and Extra. The following is an explanation of the possible occurrence of these fields:

1.  id

     My understanding is the identification of the order in which the SQL is executed, the SQL is executed from large to small

1. When the ids are the same, the execution order is from top to bottom

2. If it is a subquery, the serial number of the id will increase. The larger the id value, the higher the priority and the first to be executed.

3. If the id is the same, it can be considered as 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

      Indicates the type of each select clause in the query

(1) SIMPLE (simple SELECT, not using UNION or subqueries, etc.)

(2) PRIMARY (if the query contains any complex subparts, the outermost select is marked as PRIMARY)

(3) UNION (the second or subsequent SELECT statement in UNION)

(4) DEPENDENT UNION (the second or subsequent SELECT statement in UNION, depending on the outside query)

(5) UNION RESULT (result of UNION)

(6) SUBQUERY (the first SELECT in the subquery)

(7) DEPENDENT SUBQUERY (the first SELECT in the subquery, depending on the outer query)

(8) DERIVED (SELECT of derived table, subquery of FROM clause)

(9) UNCACHEABLE SUBQUERY (the result of a subquery cannot be cached, the first row of the outer link must be re-evaluated)

 

Three, table

Show which table the data in this row is about, sometimes not the real table name, what you see is derivedx (x is a number, my understanding is the result of the execution of the first steps)

copy code
mysql> explain select * from (select * from ( select * from t1 where id=2602) a) b;
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
| id | select_type | table      | type   | possible_keys     | key     | key_len | ref  | rows | Extra |
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
|  1 | PRIMARY     | <derived2> | system | NULL              | NULL    | NULL    | NULL |    1 |       |
|  2 | DERIVED     | <derived3> | system | NULL              | NULL    | NULL    | NULL |    1 |       |
|  3 | DERIVED     | t1         | const  | PRIMARY,idx_t1_id | PRIMARY | 4       |      |    1 |       |
+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
copy code

 

Four, type

Indicates how MySQL finds the desired row in the table, also known as the "access type".

Commonly used types are:  ALL, index, range, ref, eq_ref, const, system, NULL (from left to right, poor to good performance)

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

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

range: Retrieve only rows in a given range, using an index to select rows

ref: Indicates the join matching condition of the above table, that is, which columns or constants are used to find the value on the index column

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

const, system: These types of access are used when MySQL optimizes a part of the query and converts it to a constant. If the primary key is placed in the where list, MySQL can convert the query into a constant. System is a special case of the const type. When the query table has only one row, use system

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

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

This column is completely independent of the order of the table shown in the EXPLAIN output. This means that some keys in possible_keys cannot actually be used in the generated table order.
If the column is NULL, there is no associated index. In this case, you can improve your query performance by checking the WHERE clause to see if it references certain columns or columns suitable for indexing. If so, create an appropriate index and check the query with EXPLAIN again

 

6. Key

The key column shows the key (index) that MySQL actually decided to use

If no index is selected, the key is NULL. To force MySQL to use or ignore indexes on the possible_keys column, use FORCE INDEX, USE INDEX, or IGNORE INDEX in the query.

 

、 Key_len

Indicates the number of bytes used in the index, which can be used to calculate the length of the index used in the query (the value displayed by key_len is the maximum possible length of the index field, not the actual length used, that is, key_len is calculated according to the table definition, not retrieved from the table)

Shorter lengths are better without loss of accuracy 

 

Eight, ref

Indicates the join matching condition of the above table, that is, which columns or constants are used to find the value on the index column

 

Nine, rows

 Indicates that MySQL estimates the number of rows to be read to find the desired record based on table statistics and index selection

 

10. Extra

This column contains details of how MySQL resolves the query, in the following cases:

Using where: The column data is returned from a table that only uses the information in the index without reading the actual action. This occurs when all the requested columns for the table are part of the same index, indicating that the mysql server will Filter after the row is retrieved by the storage engine

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

Using filesort: The sort operation in MySQL that cannot be done with an index is called "file sort"

Using join buffer: This value emphasizes that no index is used when fetching join conditions, and a join buffer is required to store 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.

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

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

 

 

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 SELECT operations, other operations should be rewritten as SELECT and then check the execution plan.

 

Reference: http://dev.mysql.com/doc/refman/5.5/en/explain-output.html

                http://www.cnitblog.com/aliyiyi08/archive/2008/09/09/48878.html

                http://www.cnblogs.com/gomysql/p/3720123.html

Guess you like

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