EXPLAIN Extra Information

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
简介: `EXPLAIN` 输出的 `Extra` 列提供了 MySQL 解析查询的附加信息。此列可能的值及其对应的 JSON 属性如下:- **Using filesort / using_filesort**:需额外排序。- **Using temporary / using_temporary_table**:需创建临时表。- **Deleting all rows**:删除所有行。- **Distinct / distinct**:寻找不同值。- **FirstMatch(tbl_name)**:使用半连接策略。

EXPLAIN Output Format

image.png

EXPLAIN Extra Information

EXPLAIN输出的Extra列包含有关MySQL如何解析查询的其他信息。以下列表解释了此列中可能出现的值。每个项目还指示JSON格式输出的哪个属性显示Extra值。对于其中一些,有一个特定的属性。其他则显示为消息属性的文本。
如果你想让查询尽可能快,请注意Using filesort和Using temporary的额外列值,或者在JSON格式的EXPLAIN输出中,注意Using _filesort和Using _temporary_table属性等于true。

Child of 'table' pushed join@1 (JSON: message text)

此表在可以下推到NDB内核的联接中被引用为表的子表。仅在启用下推连接时适用于NDB群集。有关更多信息和示例,请参阅ndb_join_pushdown服务器系统变量的描述。
const row not found (JSON property: const_row_not_found)
For a query such as SELECT ... FROM tbl_name, the table was empty.

Deleting all rows (JSON property: message)
对于DELETE,一些存储引擎(如MyISAM)支持以简单快速的方式删除所有表行的处理程序方法。如果发动机使用此优化,则显示此额外值。

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

FirstMatch(tbl_name) (JSON property: first_match)

tbl_name使用半连接FirstMatch连接快捷策略。

Full scan on NULL key (JSON property: message)
当优化器无法使用索引查找访问方法时,作为回退策略的子查询优化会发生这种情况。

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(和系统)表,并注意到WHERE子句始终为false。

LooseScan(m..n) (JSON property: message)
The semijoin LooseScan strategy is used. m and n are key part numbers.

No matching min/max row (JSON property: message)
No row satisfies the condition for a query such as SELECT MIN(...) FROM ... WHERE condition.

no matching row in const table (JSON property: message)
For a query with a join, there was an empty table or a table with no rows satisfying a unique index condition.

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语句,当没有SELECT部分时,EXPLAIN会显示此值。例如,它出现在EXPLAIN INSERT INTO t VALUES(10)中,因为这相当于EXPLAIN INSERT INTO t SELECT 10 FROM DUAL。

Not exists (JSON property: message)
MySQL能够对查询进行LEFT JOIN优化,并且在找到一行符合LEFT JOIN条件后,不会检查此表中前一行组合的更多行。以下是可以通过这种方式优化的查询类型的示例:
image.png

假设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访问方法来检索行。这不是很快,但比在没有索引的情况下执行连接要快。适用性标准如第8.2.1.2节“范围优化”和第8.2.1.3节“索引合并优化”所述,但上表的所有列值都是已知的,并且被视为常数。
索引从1开始编号,顺序与表中的SHOW INDEX所示的顺序相同。索引映射值N是指示哪些索引是候选的位掩码值。例如,值0x19(二进制11001)表示考虑索引1、4和5。

Scanned N databases (JSON property: message)
这表示服务器在处理对INFORMATION_SCHEMA表的查询时执行的目录扫描次数,如第8.2.3节“优化INFORMATY_SCHEMA查询”所述。N的值可以是0、1或全部。

Select tables optimized away (JSON property: message)
优化器确定1)最多应返回一行,2)要生成此行,必须读取一组确定性的行。当在优化阶段可以读取要读取的行时(例如,通过读取索引行),在查询执行期间不需要读取任何表。
当查询隐式分组时(包含聚合函数但没有GROUP BY子句),满足第一个条件。当对每个使用的索引执行一行查找时,满足第二个条件。读取的索引数量决定了要读取的行数。
考虑以下隐式分组查询:

image.png

假设MIN(c1)可以通过读取一个索引行来检索,MIN(c2)可以通过从不同的索引读取一行来检索。也就是说,对于每一列c1和c2,都存在一个索引,其中该列是索引的第一列。在这种情况下,返回一行,这是通过读取两个确定性行产生的。
如果要读取的行不是确定性的,则不会出现此Extra值。考虑以下查询:

image.png
假设(c1,c2)是一个覆盖指数。使用此索引,必须扫描c1<=10的所有行以找到最小c2值。相比之下,考虑一下这个查询:

image.png
在这种情况下,c1=10的第一索引行包含最小c2值。只需读取一行即可生成返回的行。
对于每个表保持精确行数的存储引擎(如MyISAM,但不包括InnoDB),对于缺少WHERE子句或始终为真且没有GROUP BY子句的count(*)查询,可能会出现此Extra值。(这是隐式分组查询的一个实例,其中存储引擎影响是否可以读取确定数量的行。)

Skip_open_table, Open_frm_only, Open_full_table (JSON property: message)

这些值表示应用于对INFORMATION_SCHEMA表的查询的文件打开优化,如第8.2.3节“优化INFORMATER_SCHEMA查询”所述。
image.png

Start temporary, End temporary (JSON property: message)

This indicates temporary table use for the semijoin Duplicate Weedout strategy. 这表示临时表用于半连接重复淘汰策略。

unique row not found (JSON property: message)

For a query such as SELECT ... FROM tbl_name, no rows satisfy the condition for a UNIQUE index or PRIMARY KEY on the table.

Using filesort (JSON property: using_filesort)
MySQL必须进行额外的传递,以了解如何按排序顺序检索行。排序是通过根据连接类型遍历所有行,并存储与WHERE子句匹配的所有行的排序键和指向该行的指针来完成的。然后对键进行排序,并按排序顺序检索行。见第8.2.1.14节“按优化排序”。

Using index (JSON property: using_index)
仅使用索引树中的信息从表中检索列信息,而不必进行额外的查找来读取实际行。当查询仅使用属于单个索引的列时,可以使用此策略。
对于具有用户定义聚集索引的InnoDB表,即使Extra列中没有Using index,也可以使用该索引。如果类型是索引,键是PRIMARY,则会出现这种情况。

Using index condition (JSON property: using_index_condition)
通过访问索引元组并首先测试它们来确定是否读取整个表行,从而读取表。这样,索引信息用于延迟(“向下推”)读取整个表行,除非有必要。见第8.2.1.5节“指标条件下推优化”。

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

Using join buffer (Block Nested Loop), Using join buffer (Batched Key Access) (JSON property: using_join_buffer)
来自早期联接的表被分部分读入联接缓冲区,然后它们的行从缓冲区中用于执行与当前表的联接。(块嵌套循环)表示使用块嵌套循环算法,(批量密钥访问)表示使用批量密钥访问算法。也就是说,EXPLAIN输出前一行表中的键被缓冲,匹配的行从出现Using join buffer的行表示的表中批量提取。
在JSON格式的输出中,using _join_buffer的值始终是块嵌套循环或批处理密钥访问之一。
有关这些算法的详细信息,请参见块嵌套循环连接算法和批处理密钥访问连接。

Using MRR (JSON property: message)
使用多范围读取优化策略读取表。见第8.2.1.10节“多范围读取优化”。

Using sort_union(...), Using union(...), Using intersect(...) (JSON property: message)
这些指示了显示如何合并index_merge连接类型的索引扫描的特定算法。见第8.2.1.3节“索引合并优化”。

Using temporary (JSON property: using_temporary_table)
为了解决查询,MySQL需要创建一个临时表来保存结果。如果查询包含以不同方式列出列的GROUP BY和ORDER BY子句,则通常会发生这种情况。

Using where (JSON property: attached_condition)
WHERE子句用于限制哪些行与下一个表匹配或发送到客户端。除非您特别打算从表中获取或检查所有行,否则如果Extra值不是Using where,并且表连接类型是all或index,则查询中可能会出现问题。
在JSON格式的输出中使用where没有直接对应项;attachd_condition属性包含使用的任何WHERE条件。

Using where with pushed condition (JSON property: message)
此项仅适用于NDB表。这意味着NDB Cluster正在使用条件下推优化来提高无索引列和常数之间直接比较的效率。在这种情况下,条件被“下推”到集群的数据节点,并在所有数据节点上同时进行评估。这消除了在网络上发送不匹配行的需要,并且在可以但不使用条件推送的情况下,可以将此类查询的速度提高5到10倍。有关更多信息,请参阅第8.2.1.4节“发动机状态下推压优化”。

Zero limit (JSON property: message)
The query had a LIMIT 0 clause and cannot select any rows.

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
11月前
|
数据库
解决which is not functionally dependent on columns in GROUP BY clause;...sql_mode=only_full_group_by
解决which is not functionally dependent on columns in GROUP BY clause;...sql_mode=only_full_group_by
207 0
|
SQL 关系型数据库 BI
PG:什么是grouping sets
PG:什么是grouping sets
123 0
1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'information_schema.PROFILING.SEQ' which is not functionally dependent on columns in GROUP BY clause
1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'information_schema.PROFILING.SEQ' which is not functionally dependent on columns in GROUP BY clause
196 0
1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'information_schema.PROFILING.SEQ' which is not functionally dependent on columns in GROUP BY clause
|
存储 缓存 关系型数据库
explain 之 extra 介绍|学习笔记
快速学习 explain 之 extra 介绍
139 0
|
SQL 关系型数据库 MySQL
Exploiting hard filtered SQL Injections
http://websec.wordpress.com/2010/03/19/exploiting-hard-filtered-sql-injections/ While participa...
1200 0
|
SQL 数据库
Database specific hint in One order search
Database specific hint in One order search
Database specific hint in One order search
How to find where settype DB table COMM_PRMAT is accessed without debugging
How to find where settype DB table COMM_PRMAT is accessed without debugging
How to find where settype DB table COMM_PRMAT is accessed without debugging
|
SQL Oracle 算法
PostgreSQL 12 preview - plan_cache_mode参数控制强制使用plan cache或强制custom plan (force_custom_plan and force_generic_plan)
标签 PostgreSQL , plan_cache_mode 背景 plan cache在OLTP中,可以大幅降低生成sql parser, 执行计划的开销。 但是在某些场景中,plan cache可能成为问题,比如AP类型的场景中,由于SQL 输入条件的变化(通常AP业务涉及的条件可能比较容易出现这样的问题),可能导致plan cache并不是最佳的执行计划。
1365 0
|
SQL 关系型数据库
mysql5.7 ORDER BY clause is not in GROUP BY clause and contains nonaggregated column
好郁闷,这句sql看着很正常,可是他就是报错,百度查资料基本都是修mysql的配置文件 SELECT item_id from tb_order_item as aa,tb_order as bb WHERE aa.
1568 0