Actually explain the MySQL execution plan, the interviewer "takes me" on the spot

explain or desc to obtain information on how MySQL executes select statements.

The result contains many columns

1 Description of each column field

1.1 id

SELECT identifier. This is the sequence number of the SELECT in the query, indicating the order in which the select clause or operation table is executed in the query. If the row refers to the union result of other rows, the value can be NULL.

The id number is divided into three situations:

1. The id is the same, then the execution order is from top to bottom

explain se1ect * from emp e join dept d on e.deptno = d.deptnojoin salgrade sg on e.sa1 between sg.1osal and sg.hisal;

1. The id is different. If it is a subquery, the id's serial number will increase. The larger the id value, the higher the priority, and the earlier it will be executed

explain select * from emp e where e.deptno in (select d.deptno from dept d where d.dname = 'SALES');

1. Same and different ids exist at the same time:

   The same can be considered as a group, executed in order from top to bottom. In all groups, the greater the id value, the earlier the execution

exp1ain select * from emp e join dept d on e.deptno = d.deptno join salgrade sg on e.sa1between sg.1osal and sg.hisal where e. deptno in (select d.deptno from dept d whered.dname = 'SALES');select_ type

1.2 select_type

It is mainly used to distinguish the type of SELECT, whether it is a normal query, a joint query or a subquery:

• simple (simple table, that is, no table join or subquery)
• primary (primary query, that is, external query)
• union (the second or subsequent query statement in union)
• subquery (the first select in the subquery)

1.3 table

Output result set. Which table the corresponding row is accessing, the table name or alias, may be a temporary table or a union merge result set.

1. If it is a specific table name, it indicates that the data is obtained from the actual physical table, of course, it can also be an alias of the table

2. The table name is in the form of derivedN, indicating that the derived table generated by the query with id N is used

   When there is a union result, the table name is in the form of union n1, n2, etc., n1, n2 represent the id of participating in the union

   The type column describes how to join the table.

Represents the way that MySQL finds the required row in the table, or it is called 访问类型.
Common types: all, index, range, ref, eq_ref, const, system, null, the performance varies from poor to good.

Generally, it is necessary to ensure that the query reaches at least the range level, preferably ref.

1.4.1 ALL

The simplest violent full table scan, MySQL traverses the entire table to find matching rows, the efficiency is the worst.
Perform a full table scan for each combination of rows from the previous table. If the table is the first table that is not marked as const, it is usually not good, and performance is usually very bad in all other cases. In general, you can avoid ALL by adding indexes that allow rows to be retrieved from the table based on constant values ​​or column values ​​in the earlier table.

explain select * from film where rating > 9;

1.4.2 index

The connection type is the same as ALL, except for scanning the index tree. This happens in two ways:

1. If the index is a covering index for the query and can be used to satisfy all the data required in the table, only the index tree is scanned.

   In this case, the Extracolumn is displayed Using index.

   Index-only scans are usually faster than ALL because the size of the index is usually smaller than the table data.

2. Perform a full table scan using reads to the index to find data rows in index order.

   The Extra column is not displayed Using index.

When the query only uses columns that are part of a single index, MySQL can use this connection type.

explain select title from film;

1.4.3 range

Use the index to query rows and retrieve only rows within a given range. The keycolumn in the output row indicates which index is used. key_lenContains the longest key part used. This type of refcolumn is NULL.

When using =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, LIKE, or IN() operators to compare keycolumns with constants, you can use range:
index range scan, Common<,<=,>,>=,between

SELECT * FROM tbl_nameWHERE key_column = 10;SELECT * FROM tbl_nameWHERE key_column BETWEEN 10 and 20;SELECT * FROM tbl_nameWHERE key_column IN (10,20,30);SELECT * FROM tbl_nameWHERE key_part1 = 10 AND key_part2 IN (10,20,30);

1.4.4 index_subquery

This connection type is similar to unique_subquery. It replaces INsubqueries, but applies to non-unique indexes in subqueries of the following form:

value IN (SELECT key_column FROM single_table WHERE some_expr)

1.4.5 unique_subquery

This type replaces eq_ref with some IN subqueries of the following form:

value IN (SELECT primary_key FROM single_table WHERE some_expr)

unique_subquery is just an index search function, which can completely replace subqueries to improve efficiency.

1.4.6 index_merge

This join type indicates the use of index merge optimization. In this case, the key column in the output row contains the list of indexes used, and key_len contains the list of the longest key part of the indexes used.

1.4.7 ref_or_null

This connection type is similar to ref, but MySQL will additionally search for rows that contain NULL values. This join type optimization is most commonly used to resolve subqueries. In the following example, MySQL can use ref_or_null connection to process ref_table:

SELECT * FROM ref_tableWHERE key_column=expr OR key_column IS NULL;

1.4.8 fulltext

Use the FULLTEXT index to perform the connection.

1.4.9 ref

For each row combination in the previous table, all rows with matching index values ​​will be read from this table.
If the connection uses only the leftmost prefix of the key, or if the key is not a PRIMARY KEY or UNIQUE index (that is, if the connection cannot select a single row based on the key value), ref will be used.
If the key used only matches a few rows, this is a good type of join.

ref can be used for indexed columns that are compared using the = or <=> operator. In the following example, MySQL can use ref join to handle ref_table:

SELECT * FROM ref_table WHERE key_column=expr;SELECT * FROM ref_table,other_tableWHERE ref_table.key_column=other_table.column;SELECT * FROM ref_table,other_tableWHERE ref_table.key_column_part1=other_table.columnAND ref_table.key_column_part2=1;

1.4.10 eq_ref

For each combination of rows in the previous table, read one row from this table. In addition to system and const types, this is the best connection type.
It will be used when connecting all parts of the index and the index is PRIMARY KEY or UNIQUE NOT NULL.

Similar to ref, the difference is that the index used is a unique index. For each index key value, there is a record in the table that matches; in
simple terms, multi-table connection uses primary key or unique index as the association condition.

eq_ref can be used for indexed columns that are compared using the = operator. The comparison value can be a constant or an expression using a column in the table read before this table. In the following example, MySQL can use eq_ref connection to process ref_table:

SELECT * FROM ref_table,other_tableWHERE ref_table.key_column=other_table.column;SELECT * FROM ref_table,other_tableWHERE ref_table.key_column_part1=other_table.columnAND ref_table.key_column_part2=1;

1.4.11 const

The table has at most one matching row, which is read at the beginning of the query. Because there is only one row, the rest of the optimizer can treat the values ​​of the columns in this row as constants. const tables are very fast because they are only read once.

When comparing all parts of a PRIMARY KEY or UNIQUE index with a constant value, const will be used. In the following query, tbl_name can be used as a const table:

SELECT * FROM tbl_name WHERE primary_key=1;SELECT * FROM tbl_nameWHERE primary_key_part1=1 AND primary_key_part2=2;

1.4.12 system

This table has only one row (system table). This is a special case of the const connection type.

type null, MySQL does not need to access the database to get the result directly.

1.5 possible_keys

Possible indexes for this query

1.6 key

The exact index used in this query

1.7 ref

Which field or constant is used with key

1.8 rows

How many rows were scanned by this query? This is an estimate and is not accurate.

1.9 filtered

Percentage of data filtered by this query

1.10 extra

Additional information.

using filesort

Use EXPLAIN to check whether MySQL can use the index to parse the ORDER BY clause:

• If the Extra column of the EXPLAIN output does not contain Using filesort, the index is used and file sorting is not performed

• If the Extra column of the EXPLAIN output contains the file sorting in use, the index is not used, but the whole file sorting is performed

EXPLAIN cannot distinguish whether the optimizer performs file sorting in memory.

The use of memory file sorting can be seen in the trace output of the optimizer.

Find filesort_priority_queue_optimization.

using temporary

Create a temporary table to save the intermediate results, and delete the temporary table after the query is completed

using index

Indicates that the current query is a covering index, which reads data directly from the query without accessing the data table.
If “using where” appears at the time, it means that the index is used to search for the key value of the index;
if not, it means that the index is used to read the data, not the real search

using where

Use where for conditional filtering

using join buffer

Use connection cache

impossible where

The result of the where statement is always false

no matching row in const table

For queries with joins, there is an empty table or a table with no rows that satisfy the unique index condition.

In fact, there are many more, so I won’t describe them too much.

explain extended

MySQL 4.1 introduces the explain extended command, through explain extended plus show warnings, you can view the operation done by the optimizer before MySQL is actually executed

explain select * from users;show warnings;

It can be seen from the warning field that some constant conditions will be removed, and the result of explain extended can be used to quickly obtain a clearer and more readable SQL statement.

2 show profile

SHOW PROFILE and SHOW PROFILES statements display summary information, which indicates the resource usage of statements executed during the current session.

The SHOW PROFILE and SHOW PROFILES statements have been deprecated and will be removed in future versions of MySQL, and the performance mode will be used instead. Here we will briefly introduce it, everyone knows that this is enough.

• Check if profile is turned on

It can be seen that profiling is turned off by default.

Profiling can be started at the session level through the set statement:

set profiling=1;

You can view the status and time-consuming of each thread during execution.
The sendingdata state indicates that the MySQL thread begins to access the data row and returns the result to the client, not just to the client. Because in the sending data state, the MySQL thread often needs to do a lot of disk read operations; so it is often The most time-consuming state of the entire query.

Support to select all, cpu, block io, context, switch, page faults and other details to view what resources MySQL is using too much time, for example, choose to view the time-consuming cpu

show profile cpu for query 6;

Comparing the operation of MyISAM, the same count (*) operation is performed, the profile is checked, the Innodb table has experienced the Sending data state, and the MyISAM table does not need to access the data at all

If you are interested in the MySQL source code , you can view the source code file corresponding to each step of the sql parsing execution process through show profile source for query

show profile source for query 6

3 trace analysis optimizer

MySQL 5.6 is provided. Through the trace file, you can further understand the choice of the optimizer and better understand the behavior of the optimizer.

How to use

Turn on trace, set the format to json, and set the maximum memory that trace can use to avoid the incomplete display due to the small default memory during the analysis process

set optimizer_trace="enabled=on",end_markers_in_json=on;set optimizer_trace_max_mem_size=1000000;

Next execute the sql statement of trace

select * from ....where....

Finally, check the information_schema.optimizer_trace to know how Mysql executes sql

select * from information_schema.optimizer_trace