[Mysql tuning] (c): Explain interpretation of the implementation plan

introduction: 

  The actual project development, because we do not know what time the actual query occurs the database, the database software is how to scan the table, how to use the index, therefore, we can perceive only sql statement run time, the size of the data when not, the query is instant, so when writing sql statements rarely take into account the problem of performance. But when the data size increases, such as the millions, million, we ran the same sql statement only to find nothing ever, this time to know the size of the data it has limited the speed of our queries. So, query optimization and index becomes very important.

A, Explain Profile

1, the role of

      When we query before the query can be estimated in advance exactly how many rows to be involved, which indexes to use, run time? The answer is energy, mysql provides the appropriate functionality and syntax to achieve this functionality.

By Explain, we can analyze the following results:

  •     Reading order table
  •     Data read operation type of operation
  •     Which indexes can be used
  •     Which indexes are actually used
  •     References between tables
  •     Each table of how many rows the query optimizer

2, use

Before SQL statements plus a "EXPLAIN" can be. For example, we have to analyze the following SQL statement:

mysql> EXPLAIN SELECT *  FROM person_info_large ;
+----+-------------+---------+------+---------------+------+---------+------+--------+-------+
| id | select_type | table   | type | possible_keys | key  | key_len | ref  | rows   | Extra |
+----+-------------+------ --+------+---------------+------+---------+------+--------+-------+

Two, Explain Plan of Implementation of the fields Interpretation

1、id

  Multi-table query tables in the order of execution of sentence

id There are three cases:

  • The same id, execution order from top to bottom
mysql> EXPLAIN SELECT * from dept t1,dept t2,dept t3 WHERE t1.deptno=t2.deptno AND t2.deptno=t3.deptno;
+----+-------------+-------+------+---------------+------+---------+------+------+---------------------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra                           |
+----+-------------+-------+------+---------------+------+---------+------+------+---------------------------------+
|  1 | SIMPLE      | t1    | ALL  | NULL          | NULL | NULL    | NULL |   10 | NULL                            |
|  1 | SIMPLE      | t2    | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where; Using join buffer  |
|  1 | SIMPLE      | t3    | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where; Using join buffer  |
+----+-------------+-------+------+---------------+------+---------+------+------+---------------------------------+
3 rows in set (0.00 sec)
  • id not the same, if a sub-query, the number is incremented id, id value the greater the higher the priority, the first to be executed

 

 

  • Unlike the same id exist, id value is larger the higher the priority, id performed in the same order from top to bottom
mysql> EXPLAIN SELECT * from (SELECT * FROM dept )t1,dept t2  WHERE t1.deptno=t2.deptno;
+----+-------------+------------+------+---------------+-------------+---------+----------------+------+-------+
| id | select_type | table      | type | possible_keys | key         | key_len | ref            | rows | Extra |
+----+-------------+------------+------+---------------+-------------+---------+----------------+------+-------+
|  1 | PRIMARY     | t2         | ALL  | NULL          | NULL        | NULL    | NULL           |   10 | NULL  |
|  1 | PRIMARY     | <derived2> | ref  | <auto_key0>   | <auto_key0> | 3       | test.t2.deptno |    2 | NULL  |
|  2 | DERIVED     | dept       | ALL  | NULL          | NULL        | NULL    | NULL           |   10 | NULL  |
+----+-------------+------------+------+---------------+-------------+---------+----------------+------+-------+
3 rows in set (0.00 sec)

 

 

2、select_type

      It represents the type of query is mainly used to distinguish between normal query, the union query, sub query of complex queries.

   There are these types of the following types of queries:

  •    SIMPLE   simple select query, the query does not contain subqueries or UNION

  •     PRIMARY   query if contain any complex sub-section, the outermost query were marked as PRIMARY

  •     SUBQUERY   contains subqueries in the SELECT list or WHERE

  •     DERIVED   subquery contained in the FROM list is marked DERIVED (derivative), MySQL will recursively these sub-queries, the results in a temporary table

  •    UNION   If after the second SELECT appears UNION, were labeled UNION: UNION if included in the FROM clause of a subquery, SELECT will be marked as the outer layer: DERIVED

  •     UNION RESULT get results from a UNION SELECT table

3、table

   The implementation of the current statement goes on table

4、type

   Display query uses what type, of the type comprising a common type comprising several shown below:

+-------+-------------+---------+------+---------------+----------------+------+
| all   |   index     | range   | ref  |    eq_fef     |  system,const  | NULL |
+-------+-------------+------ --+------+---------------+----------------+------+

From best to worst are:

                     system > const > eq_ref > ref >fulltext>range > index_merge>index > all

  • system  table has only one row (equal to the system table), which is a special type const column, usually does not occur, this may be negligible
  • const     indicated by the index once found, const for comparing the primary key or unique index. Because only one row of data matching, so fast. As will be placed where the primary key list, MySQL the query can be converted to a constant.
mysql> EXPLAIN  select  *  FROM (select  *  FROM dept t1 where id=1)t2;
+----+-------------+-------------------+--------+---------------+---------+---------+-------+------+-------+
| id | select_type | table             | type   | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-------------------+--------+---------------+---------+---------+-------+------+-------+
|  1 | PRIMARY     | <derived2>        | system | NULL          | NULL    | NULL    | NULL  |    1 | NULL  |
|  2 | DERIVED     | t1                | const  | PRIMARY       | PRIMARY | 4       | const |    1 | NULL  |
+----+-------------+-------------------+--------+---------------+---------+---------+-------+------+-------+
2 rows in set (0.00 sec)

For plain speaking system in terms of table t2 there are 0 (empty table) or a record, for  const terms of tables t1 filtered through the primary key or data and the data set has a unique index to a record and only

As shown above, the id is 1, table shows <derived2> , referred to herein as a data table t1 filter produces a result set derived from the table, I understand the temporary table.

  • eq_ref   unique index scan, for each index key, the table is only one matching record. Common in the primary key or unique index scan
mysql> EXPLAIN SELECT * from dept t1,dept t2 WHERE t1.id=t2.id ;
+----+-------------+-------+--------+---------------+---------+---------+------------+------+-------------+
| id | select_type | table | type   | possible_keys | key     | key_len | ref        | rows | Extra       |
+----+-------------+-------+--------+---------------+---------+---------+------------+------+-------------+
|  1 | SIMPLE      | t1    | ALL    | PRIMARY       | NULL    | NULL    | NULL       |   10 | NULL        |
|  1 | SIMPLE      | t2    | eq_ref | PRIMARY       | PRIMARY | 4       | test.t1.id |    1 | NULL |
+----+-------------+-------+--------+---------------+---------+---------+------------+------+-------------+
2 rows in set (0.00 sec)

Plain talk is associated table t2 field is a primary key or a unique index corresponding fields of table t1 is associated primary key or unique index, t1 and t2 for one match

  • ref   non-unique index scan returns all rows matching a single value, in essence, is a kind of index access, which returns all rows that match a single value, however, may find it more in line with the conditions of the line, so he should belong to a mixture of search and scan.
mysql> EXPLAIN SELECT * from emp t1 ,dept t2 WHERE t1.deptno=t2.deptno;
+----+-------------+-------+------+---------------+--------------+---------+----------------+-------+-------+
| id | select_type | table | type | possible_keys | key          | key_len | ref            | rows  | Extra |
+----+-------------+-------+------+---------------+--------------+---------+----------------+-------+-------+
|  1 | SIMPLE      | t2    | ALL  | NULL          | NULL         | NULL    | NULL           |    10 | NULL  |
|  1 | SIMPLE      | t1    | ref  | index_deptno  | index_deptno | 3       | test.t2.deptno | 27685 | NULL  |
+----+-------------+-------+------+---------------+--------------+---------+----------------+-------+-------+
2 rows in set (0.00 sec)

T1 plain talk is not associated with the field is a field associated with a primary key or primary keys or unique index unique index corresponding thereto and t2, t1 and t2 for many matching

  • range   retrieve only to the line given range, using an index to select the rows, key column shows the use of which index, generally appear between is where in your statement, <,>, in other queries, this ratio index range scan full table scan is better, because it only needs to start at some point in the index, ended at another point, you do not have to scan the entire index.
  • index   Full Index Scan, Index and All index difference is the type of traversing the index tree only. This is usually faster than ALL, because the index file is usually smaller than the data file. (In other words, although all are read and Index full table, but the index is read from the index, but all are read from the hard disk)
  • All  Full Scan the Table will traverse the whole table to find matching rows

5、possible_keys 和 key

          possible_keys and key prerequisite for taking the index, if you do not take the index possible_keys and key value is NULL

  • possible_keys display index in this table may be applied, one or more. Queries related to the field if there is an index, the index will be listed, but not necessarily the actual query.
     
  • key 

6, key_len

7、ref

8、rows

9、Extra

 

Guess you like

Origin www.cnblogs.com/kongliuyi/p/10669380.html