MySQL执行计划

Posted DB-Engineer

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MySQL执行计划相关的知识，希望对你有一定的参考价值。

mysql执行计划

EXPLAIN 语法

{EXPLAIN | DESCRIBE | DESC}
    tbl_name [col_name | wild]

{EXPLAIN | DESCRIBE | DESC}
    [explain_type]
    {explainable_stmt | FOR CONNECTION connection_id}

explain_type: {
    EXTENDED
  | PARTITIONS
  | FORMAT = format_name
}

format_name: {
    TRADITIONAL
  | JSON
}

explainable_stmt: {
    SELECT statement
  | DELETE statement
  | INSERT statement
  | REPLACE statement
  | UPDATE statement
}

 

1. 使用EXPLAIN优化查询

EXPLAIN语句提供有关MySQL如何执行语句的信息：

  • EXPLAIN适用于SELECT，DELETE，INSERT，REPLACE和UPDATE语句。

  • 当EXPLAIN与可解释的语句一起使用时，MySQL会显示优化器中有关语句执行计划的信息。也就是说，MySQL解释了它将如何处理语句，包括有关表如何连接以及以何种顺序连接的信息。

  • 当EXPLAIN与FOR CONNECTION connection_id将显示connection_id执行的语句的执行计划。

  • 对于SELECT语句，EXPLAIN会生成可以使用SHOW WARNINGS显示的其他执行计划信息。

  • EXPLAIN对于检查涉及分区表的查询很有用。

  • FORMAT选项可用于选择输出格式。 TRADITIONAL以表格格式显示输出。如果没有显示定义FORMAT选项，则默认值为TRADITIONAL。 JSON格式以JSON格式显示信息。

在EXPLAIN的帮助下，可以看到应该向表添加索引的位置，以便通过使用索引查找行来更快地执行语句。还可以使用EXPLAIN来检查优化程序是否以最佳顺序连接表。要提示优化器使用与SELECT语句中命名表的顺序相对应的连接顺序，请使用SELECT STRAIGHT_JOIN而不是SELECT来开始语句。 （请参见“SELECT语法”。）但是，STRAIGHT_JOIN可能会阻止使用索引，因为它会禁用半连接转换。请参见“使用半连接转换优化子查询，派生表和视图引用”。

优化器trace有时可以提供与EXPLAIN的信息互补的信息。但是，优化程序跟踪格式和内容可能会在不同版本之间发生变化。有关详细信息，请参阅MySQL内部：跟踪优化程序。

如果在您认为应该使用索引时遇到问题，请运行ANALYZE TABLE以更新可能影响优化程序所做选择的表统计信息，例如key的基数。请参见“ANALYZE TABLE语法”。

注意
EXPLAIN还可用于获取有关表中列的信息。 EXPLAIN tbl_name与DESCRIBE tbl_name和SHOW COLUMNS FROM tbl_name同义。

2. EXPLAIN输出格式

EXPLAIN语句提供有关MySQL如何执行语句的信息。 EXPLAIN适用于SELECT，DELETE，INSERT，REPLACE和UPDATE语句。

EXPLAIN为SELECT语句中使用的每个表返回一行信息。 它按照MySQL在处理语句时读取它们的顺序列出输出中的表。 MySQL使用嵌套循环连接方法解析所有连接。 这意味着MySQL从第一个表中读取一行，然后在第二个表，第三个表中找到匹配的行，依此类推。 处理完所有表后，MySQL会通过表列表输出所选列和回溯，直到找到有更多匹配行的表。 从该表中读取下一行，并继续下一个表。

EXPLAIN输出包括分区信息。 此外，对于SELECT语句，EXPLAIN生成扩展信息，可以使用EXPLAIN后的SHOW WARNINGS显示.

【注意】
在较旧的MySQL版本中，使用EXPLAIN PARTITIONS和EXPLAIN EXTENDED生成分区和扩展信息。 这些语法仍然可以向后兼容，但默认情况下现在启用分区和扩展输出，因此PARTITIONS和EXTENDED关键字是多余的并且已弃用。 它们的使用会导致警告，并且在将来的MySQL版本中它们将从EXPLAIN语法中删除。

您不能在同一个EXPLAIN语句中一起使用已弃用的PARTITIONS和EXTENDED关键字。 此外，这些关键字都不能与FORMAT选项一起使用。

2.1 EXPLAIN输出列

mysql> explain select * from employees.t1 where t1.emp_no in (select emp_no from employees.salaries);
+----+--------------+-------------+------------+--------+----------------+------------+---------+---------------------+---------+----------+-------------+
| id | select_type  | table       | partitions | type   | possible_keys  | key        | key_len | ref                 | rows    | filtered | Extra       |
+----+--------------+-------------+------------+--------+----------------+------------+---------+---------------------+---------+----------+-------------+
|  1 | SIMPLE       | t1          | NULL       | ALL    | NULL           | NULL       | NULL    | NULL                | 2837194 |   100.00 | Using where |
|  1 | SIMPLE       | <subquery2> | NULL       | eq_ref | <auto_key>     | <auto_key> | 4       | employees.t1.emp_no |       1 |   100.00 | NULL        |
|  2 | MATERIALIZED | salaries    | NULL       | index  | PRIMARY,emp_no | emp_no     | 4       | NULL                | 2838426 |   100.00 | Using index |
+----+--------------+-------------+------------+--------+----------------+------------+---------+---------------------+---------+----------+-------------+
3 rows in set, 1 warning (0.00 sec)

 

EXPLAIN的每个输出行都提供有关一个表的信息。如下表：

ColumnJSON NameMeaning
id select_id 查询序列号
select_type None 查询类型
table table_name 输出行所引用的表
partitions partitions 匹配的分区
type access_type 连接使用的类型
possible_keys possible_keys 指出 MySQL 能在该表中使用哪些索引有助于查询。如果为空，说明没有可用的索引
key key 实际选择的索引
key_len key_length 使用的索引的长度。在不损失精确性的情况下，长度越短越好
ref ref 显示索引的哪一列被使用了
rows rows MYSQL 认为必须检查的用来返回请求数据的行数
filtered filtered 按表条件过滤行的百分比
Extra None 附加信息

  • id(JSON Name: select_id)
    MySQL Query Optimizer 选定的执行计划中查询的序列号。表示查询中执行 select 子句或操作表的顺序， id 值越大优先级越高，越先被执行。 id 相同，执行顺序由上至下。

  • select_type (JSON name: none)
    SELECT的类型，可以是下表中列出的任何类型。

select_type ValueJSON NameMeaning
SIMPLE None 简单的SELECT（不使用UNION或子查询）
PRIMARY None 最外层的SELECT
UNION None UNION 中的第二个或随后的 select 查询， 不依赖于外部查询的结果集
DEPENDENT UNION dependent (true) UNION中的第二个或随后的SELECT语句，依赖于外部查询
UNION RESULT union_result UNION 查询的结果集
SUBQUERY None 子查询中的第一个SELECT查询，不依赖于外部查询的结果集
DEPENDENT SUBQUERY dependent (true) 子查询中的第一个SELECT，依赖于外部查询的结果集
DERIVED None 用于 from 子句里有子查询的情况。 MySQL会递归执行这些子查询，把结果放在临时表里
MATERIALIZED materialized_from_subquery 物化子查询
UNCACHEABLE SUBQUERY cacheable (false) 结果集不能被缓存的子查询，必须重新为外层查询的每一行进行评估
UNCACHEABLE UNION cacheable (false) UNION 中的第二个或随后的 select 查询，属于不可缓存的子查询

　　DEPENDENT通常表示使用相关子查询。

DEPENDENT SUBQUERY评估与UNCACHEABLE SUBQUERY评估不同。 对于DEPENDENT SUBQUERY，子查询仅针对来自其外部上下文的变量的每组不同值重新评估一次。 对于UNCACHEABLE SUBQUERY，将为外部上下文的每一行重新评估子查询。

　　子查询的可缓存性与查询缓存中查询结果的缓存不同（详见“查询缓存如何操作”）。 查询执行期间发生子查询缓存，而查询缓存仅在查询执行完成后用于存储结果。

使用EXPLAIN指定FORMAT = JSON时，输出没有直接等同于select_type的单个属性; query_block属性对应于给定的SELECT。 可以使用与刚显示的大多数SELECT子查询类型等效的属性（示例为MATERIALIZED的materialized_from_subquery），并在适当时显示。 SIMPLE或PRIMARY没有JSON等价物。

非SELECT语句的select_type值显示受影响表的语句类型。 例如，对于DELETE语句，select_type是DELETE。

  • table (JSON name: table_name)
    输出行引用的表的名称。这也可以是以下值之一：
    • <unionM,N>：该行指的是id值为M和N的行的并集。
    • <derivedN>：该行引用id值为N的行的派生表结果。例如，派生表可能来自FROM子句中的子查询。
    • <subqueryN>：该行引用id值为N的行的具体化子查询的结果

  • partitions (JSON name: partitions)
    记录将与查询匹配的分区。对于非分区表，该值为NULL。

  • type (JSON name: access_type)
    连接类型。用于描述不同的连接类型

  • possible_keys (JSON name: possible_keys)
    possible_keys指出 MySQL 能在该表中使用哪些索引有助查询。如果为空，说明没有可用的索引

  • key (JSON name: key)
    key列表示MySQL实际决定使用的key（索引）。如果MySQL决定使用其中一个possible_keys索引来查找行，那么该索引将被列为key value。

    key可能会命名possible_keys值中不存在的索引。如果所有possible_keys索引都不适合查找行，则会发生这种情况，但查询选择的所有列都是其他索引的列。也就是说，命名索引覆盖了所选列，因此虽然它不用于确定要检索的行，但索引扫描比数据行扫描更有效。

    对于InnoDB，即使查询还选择主键，辅助索引也可能覆盖所选列，因为InnoDB将主键值与每个辅助索引一起存储。如果key为NULL，则MySQL找不到用于更有效地执行查询的索引。

    要强制MySQL使用或忽略possible_keys列中列出的索引，请在查询中使用FORCE INDEX，USE INDEX或IGNORE INDEX。请参考“索引hint”。

    对于MyISAM表，运行ANALYZE TABLE可帮助优化器选择更好的索引。对于MyISAM表，myisamchk --analyze也是如此。

  • key_len (JSON name: key_length)
    key_len列使用的索引的长度。在不损失精确性的情况下，长度越短越好

  • ref (JSON name: ref)
    ref列显示哪些列或常量与key列中指定的索引进行比较，以从表中选择行。

    如果值为func，则使用的值是某个函数的结果。 要查看哪个函数，请使用EXPLAIN之后的SHOW WARNINGS来查看扩展的EXPLAIN输出。 该函数实际上可能是算术运算符等运算符。

  • rows (JSON name: rows)
    rows列指示MySQL认为必须检查以执行查询的行数。
    对于InnoDB表，此数字是估计值，可能并不总是准确的。

  • filtered (JSON name: filtered)
    filtered列指示将按表条件筛选的表行的估计百分比。 最大值为100，这意味着不会对行进行过滤。 值从100开始减少表示过滤量增加。 rows显示已检查的估计行数，rows×filtered显示将与下表连接的行数。 例如，如果行为1000且过滤为50.00（50％），则使用下表连接的行数为1000×50％= 500。

  • Extra (JSON name: none)
    此列包含有关MySQL如何解析查询的其他信息。 有关不同值的说明，请参阅EXPLAIN Extra 信息。

2.2 EXPLAIN join 类型

EXPLAIN输出的type列描述了表的连接方式。以下列表描述了从最佳类型到最差类型的连接类型：

  • system
    表仅有一行(=系统表)。这是 const 连接类型的一个特例。

  • const
    该表最多只有一个匹配行，在查询开头读取。 因为只有一行，所以优化器的其余部分可以将此行中列的值视为常量。 const表非常快，因为它们只读一次。

    当将PRIMARY KEY或UNIQUE索引的所有部分与常量值进行比较时，将使用const。 在以下查询中，tbl_name可用作const表：

    SELECT * FROM tbl_name WHERE primary_key=1;

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

     

  • eq_ref
    除 const 类型外最好的可能实现的连接类型。它用在一个索引的所有部分被连接使用并且索引是 UNIQUE 或 PRIMARY KEY， 对于每个索引键，表中只有一条记录与之匹配

    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;

     

  • ref
    连接不能基于关键字选择单个行，可能查找到多个符合条件的行。叫做 ref 是因为索引要跟某个参考值相比较。这个参考值或者是一个常数，或者是来自一个表里的多表查询的结果值

    ref可用于使用=或<=>运算符进行比较的索引列。 在以下示例中，MySQL可以使用ref join来处理ref_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;

     

  • fulltext
    使用FULLTEXT索引执行连接。

  • ref_or_null
    这种连接类型与ref类似，但附加说明MySQL会对包含NULL值的行进行额外搜索。 此连接类型优化最常用于解析子查询。 在以下示例中，MySQL可以使用ref_or_null连接来处理ref_table：

    SELECT * FROM ref_table
WHERE key_column=expr OR key_column IS NULL;

     

  • index_merge
    此连接类型表示使用了索引合并优化。 在这种情况下，输出行中的key列包含使用的索引列表，key_len包含所用索引的最长键部分列表。详见 index merge optimization

    root@localhost [test] 09:51:37> explain select * from a force index(idx_1,idx_2) where c1=2 or c2=1;
+----+-------------+-------+------------+-------------+---------------+-------------+---------+------+------+----------+---------------------------------------+
| id | select_type | table | partitions | type        | possible_keys | key         | key_len | ref  | rows | filtered | Extra                                 |
+----+-------------+-------+------------+-------------+---------------+-------------+---------+------+------+----------+---------------------------------------+
|  1 | SIMPLE      | a     | NULL       | index_merge | idx_2,idx_1   | idx_1,idx_2 | 5,5     | NULL |    2 |   100.00 | Using union(idx_1,idx_2); Using where |
+----+-------------+-------+------------+-------------+---------------+-------------+---------+------+------+----------+---------------------------------------+
1 row in set, 1 warning (0.00 sec)

     

  • unique_subquery
    此类型替换以下形式的某些IN子查询的eq_ref：

    value IN (SELECT primary_key FROM single_table WHERE some_expr)

     

    unique_subquery只是一个索引查找函数，它可以完全替换子查询以提高效率。

  • range

    仅检索给定范围内的行，使用索引选择行。 输出行中的键列指示使用哪个索引。 key_len包含使用的最长密钥部分。 对于此类型，ref列为NULL。

    使用=，<>，>，>=，<，<=，IS NULL，<=>，BETWEEN，LIKE或IN（）运算符中的任何一个将键列与常量进行比较时，可以使用范围：

    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);

     

  • index
    全表扫描，只是扫描表的时候按照索引次序进行而不是行。主要优点就是避免了排序，但是开销仍然非常大。

    • 如果索引是查询的覆盖索引，并且可用于满足表中所需的所有数据，则仅扫描索引树。 在这种情况下，Extra列显示Using index。 仅索引扫描通常比ALL快，因为索引的大小通常小于表数据。
    • 使用索引中的读取执行全表扫描，以按索引顺序查找数据行。 使用索引不会出现在Extra列中。

    当查询仅使用属于单个索引的列时，MySQL可以使用此连接类型。

  • ALL
    对表中的每行进行全表扫描。

2.3 EXPLAIN Extra 信息

EXPLAIN输出的Extra列包含有关MySQL如何解析查询的其他信息。 以下列表说明了此列中可能出现的值。 每个项目还指示JSON格式的输出，该属性显示Extra值。 对于其中一些，有一个特定的属性。 其他显示为消息属性的文本。

  • Child of ‘table‘ pushed [email protected] (JSON: message text)
    此表在连接中被引用为表的子节点，可以将其下推到NDB内核。 仅当启用了 pushed-down连接时，才适用于NDB群集。

  • const row not found (JSON property: const_row_not_found)
    对于诸如SELECT ... FROM tbl_name之类的查询，该表为空。

  • Deleting all rows (JSON property: message)
    对于DELETE，某些存储引擎（如MyISAM）支持一种处理程序方法，该方法以简单快捷的方式删除所有表行。 如果引擎使用此优化，则会显示此附加值。

  • Distinct (JSON property: distinct)
    MySQL正在寻找不同的值，因此它在找到第一个匹配行后停止为当前行组合搜索更多行。

  • FirstMatch(tbl_name) (JSON property: first_match)
    半连接FirstMatch连接快捷方式

  • Full scan on NULL key (JSON property: message)
    当优化程序无法使用 index-lookup 访问时，子查询优化将作为回退策略发生。

  • Impossible HAVING (JSON property: message)
    HAVING子句始终为false，无法查询任何行。

  • Impossible WHERE (JSON property: message)
    WHERE子句始终为false，无法查询任何行。

  • Impossible WHERE noticed after reading const tables (JSON property: message)
    MySQL已经读取了所有const（和system）表，并注意到WHERE子句始终为false。

  • LooseScan(m..n) (JSON property: message)
    使用半连接LooseScan策略。 m和n是关键部件号。

  • No matching min/max row (JSON property: message)
    没有行满足查询的条件，例如SELECT MIN（...）FROM ... WHERE条件。

  • No matching rows after partition pruning (JSON property: message)
    对于DELETE或UPDATE，优化器在分区修剪后未发现任何要删除或更新的内容。 它与SELECT语句的Impossible WHERE的含义相似。

  • No tables used (JSON property: message)
    查询语句没有制定from子句，或者from dual子句。

    对于INSERT或REPLACE语句，EXPLAIN在没有SELECT部分??时显示该值。例如，它出现在EXPLAIN INSERT INTO VALUES（10）中，因为它等同于EXPLAIN INSERT INTO SELECT 101 FROM DUAL。

  • Not exists (JSON property: message)
    MySQL能够对查询执行LEFT JOIN优化，并且在找到与LEFT JOIN条件匹配的行之后，不会检查此表中针对上一行组合的更多行。 以下是可以通过以下方式优化的查询类型的示例：

    SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
WHERE t2.id IS NULL;

     

    假设t2.id被定义为NOT NULL。 在这种情况下，MySQL扫描t1并使用t1.id的值在t2中查找行。 如果MySQL在t2中找到匹配的行，则它知道t2.id永远不能为NULL，并且不会扫描t2中具有相同id值的其余行。 换句话说，对于t1中的每一行，MySQL需要在t2中只进行一次查找，而不管t2中实际匹配多少行。

  • Plan isn‘t ready yet (JSON property: none)
    当优化器尚未完成为在命名连接中执行的语句创建执行计划时，EXPLAIN FOR CONNECTION会出现此值。 如果执行计划输出包含多行，则其中的任何一个或全部都可以具有此Extra值，具体取决于优化程序在确定完整执行计划时的进度。

  • Range checked for each record (index map: N) (JSON property: message)
    MySQL发现没有好的索引可以使用，但发现在前面的表的列值已知后可能会使用某些索引。 对于上表中的每个行组合，MySQL检查是否可以使用range或index_merge访问方法来检索行。 这不是很快，但比执行没有索引的连接更快。

  • Scanned N databases (JSON property: message)
    这表示在处理INFORMATION_SCHEMA表的查询时服务器执行的目录扫描数。 N的值可以是0,1或all。

  • Select tables optimized away (JSON property: message)
    使用某些聚合函数来访问存在索引的某个字段时，优化器会通过索引直接一次定位到所需要的数据行完成整个查询，例如MIN()MAX()，这种也是比较好的结果之一

  • Skip_open_table, Open_frm_only, Open_full_table (JSON property: message)
    这些值表示适用于INFORMATION_SCHEMA表的查询的文件打开优化。

    • Skip_open_table：不需要打开表文件。通过扫描数据库目录，该信息已在查询中可用。
    • Open_frm_only：只需要打开表的.frm文件。
    • Open_full_table：未经优化的信息查找。必须打开.frm，.MYD和.MYI文件。
  • Start temporary, End temporary (JSON property: message)
    这表示临时表用于半连接Duplicate Weedout策略。

  • unique row not found (JSON property: message)
    对于诸如SELECT ... FROM tbl_name之类的查询，没有行满足表上UNIQUE索引或PRIMARY KEY的条件。

  • Using filesort (JSON property: using_filesort)
    表示 MySQL 会对结果使用一个外部索引排序，而不是从表里按索引次序读到相关内容。可能在内存或者磁盘上进行排序。 MySQL 中无法利用索引完成的排序操作称为“文件排序”

  • Using index (JSON property: using_index)
    仅使用索引树中的信息从表中检索列信息，而不必另外寻找读取实际行。 当查询仅使用属于单个索引的列时，可以使用此策略。

    对于具有用户定义的聚簇索引的InnoDB表，即使Extra列中不存在使用索引，也可以使用该索引。 如果type是index并且key是PRIMARY，则会出现这种情况。

  • Using index condition (JSON property: using_index_condition)
    通过访问索引元组并首先测试它们以确定是否读取完整的表行来读取表。

  • Using index for group-by (JSON property: using_index_for_group_by)
    与Using index table访问方法类似，Using group for group-by表示MySQL找到了一个索引，可用于检索GROUP BY或DISTINCT查询的所有列，而无需对实际表进行任何额外的磁盘访问。 此外，索引以最有效的方式使用，因此对于每个组，只读取少数索引条目。 有关详细信息，请参考“GROUP BY优化”。

  • Using join buffer (Block Nested Loop), Using join buffer (Batched Key Access) (JSON property: using_join_buffer)
    将联接中的表分成几部分读入连接缓冲区，然后从缓冲区中使用它们的行来与当前表执行连接。 （Block Nested Loop）表示使用块嵌套循环算法，（Batched Key Access）表示使用批量密钥访问算法。 也就是说，来自EXPLAIN输出前一行的表中的键将被缓冲，匹配的行将从连接缓冲区的行的表中批量提取。

  • Using MRR (JSON property: message)
    使用多范围读取优化策略读取表,详见mrr

  • Using sort_union(...), Using union(...), Using intersect(...) (JSON property: message)
    显示如何为index_merge连接类型合并索引扫描。 请参考“索引合并优化”。

  • Using temporary (JSON property: using_temporary_table)

　　表示 MySQL 在对查询结果排序时使用临时表。常见于排序 order by和分组查询group by

  • Using where (JSON property: attached_condition)
    通常是进行了全表引扫描后再用WHERE子句完成结果过滤，需要添加合适的索引

  • Using where with pushed condition (JSON property: message)
    此项仅适用于NDB表。 这意味着NDB Cluster正在使用条件下推优化来提高非索引列和常量之间直接比较的效率。

  • Zero limit (JSON property: message)
    该查询具有LIMIT 0子句，无法选择任何行。

3. 扩展EXPLAIN输出格式

对于SELECT语句，EXPLAIN语句生成额外的（“扩展”）信息，这些信息不是EXPLAIN输出的一部分，但可以通过在EXPLAIN之后发出SHOW WARNINGS语句来查看。 SHOW WARNINGS输出中的Message值显示优化器如何限定SELECT语句中的表名和列名，SELECT应用重写和优化规则后的样子，以及可能有关优化过程的其他注释。

可以在EXPLAIN之后使用SHOW WARNINGS语句显示的扩展信息仅针对SELECT语句生成。 SHOW WARNINGS显示其他可解释语句的空结果（DELETE，INSERT，REPLACE和UPDATE）。

【注意】
在较早的MySQL版本中，扩展信息是使用EXPLAIN EXTENDED生成的。 该语法仍然可以向后兼容，但默认情况下现在启用了扩展输出，因此EXTENDED关键字是多余的并且已弃用。 它的使用会导致警告，并且在将来的MySQL版本中它将从EXPLAIN语法中删除。

例如：

root@localhost [employees] 14:11:44> explain select * from dept_emp where emp_no in (select emp_no from employees)G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: employees
   partitions: NULL
         type: index
possible_keys: PRIMARY
          key: idx_name
      key_len: 66
          ref: NULL
         rows: 298936
     filtered: 100.00
        Extra: Using index
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: dept_emp
   partitions: NULL
         type: ref
possible_keys: PRIMARY,emp_no
          key: PRIMARY
      key_len: 4
          ref: employees.employees.emp_no
         rows: 1
     filtered: 100.00
        Extra: NULL
2 rows in set, 1 warning (0.00 sec)

root@localhost [employees] 14:11:48> show warningsG
*************************** 1. row ***************************
  Level: Note
   Code: 1003
Message: /* select#1 */ select `employees`.`dept_emp`.`emp_no` AS `emp_no`,`employees`.`dept_emp`.`dept_no` AS `dept_no`,`employees`.`dept_emp`.`from_date` AS `from_date`,`employees`.`dept_emp`.`to_date` AS `to_date` from `employees`.`employees` join `employees`.`dept_emp` where (`employees`.`dept_emp`.`emp_no` = `employees`.`employees`.`emp_no`)
1 row in set (0.00 sec)

 

以下列表描述了可以出现在SHOW WARNINGS显示的扩展输出中的特殊标记：

  • <auto_key>
    自动生成的临时表key。

  • <cache>(expr)
    表达式（例如标量子查询）执行一次，结果值保存在内存中供以后使用。 对于包含多个值的结果，可能会创建一个临时表，您将看到<临时表>。

  • <exists>(query fragment)
    子查询谓词转换为EXISTS谓词，子查询被转换，以便它可以与EXISTS谓词一起使用。

  • <in_optimizer>(query fragment)
    这是一个内部优化器对象

  • <index_lookup>(query fragment)
    使用索引查找处理查询片段以查找符合条件的行。

  • <if>(condition, expr1, expr2)
    如果条件为真，则计算为expr1，否则为expr2。

  • <is_not_null_test>(expr)
    用于验证表达式不计算为NULL的测试。

  • <materialize>(query fragment)
    用于子查询物化。

  • materialized-subquery.col_name
    对内部临时表中列col_name的引用，该列实现为保存评估子查询的结果。

  • <primary_index_lookup>(query fragment)
    使用主键查找处理查询片段以查找符合条件的行。

  • <ref_null_helper>(expr)
    这是一个内部优化器对象

  • /* select#N */ select_stmt
    SELECT与非扩展EXPLAIN输出中具有id值N的行相关联。

  • outer_tables semi join (inner_tables)
    半连接操作。

  • <temporary table>
    这表示为缓存中间结果而创建的内部临时表。







































































以上是关于MySQL执行计划的主要内容，如果未能解决你的问题，请参考以下文章

MySQL执行计划

如何查看sqlserver执行计划来判断SQL语句效率

如何查看mysql定时任务计划

MySQL系列- MySQL执行计划

Mysql学会查看sql的执行计划

mysql中如何查看优化器优化后的执行计划