id (JSON 名称: select_id)

SELECT 标识符。这是查询中 SELECT 的序号。如果该行引用其他行的联合结果，则该值可以是 NULL。在这种情况下，table 列显示类似 <unionM,N> 的值，表示该行引用 id 值为 M 和 N 的行的联合。

select_type (JSON 名称: 无)

SELECT 的类型，可以是下表中显示的任何一种。JSON 格式的 EXPLAIN 将 SELECT 类型公开为 query_block 的属性，除非它是 SIMPLE 或 PRIMARY。JSON 名称（如果适用）也显示在表中。

DEPENDENT 通常表示使用相关子查询。请参阅 第 15.2.15.7 节“相关子查询”。

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 名称：table_name）

输出行所引用的表的名称。这也可以是以下值之一

partitions（JSON 名称：partitions）

查询将从中匹配记录的分区。对于非分区表，该值为 NULL。请参阅 第 26.3.5 节“获取有关分区的信息”。

type（JSON 名称：access_type）

连接类型。有关不同类型的描述，请参阅 EXPLAIN 连接类型。

possible_keys（JSON 名称：possible_keys）

possible_keys 列指示 MySQL 可以从中选择查找此表中的行的索引。请注意，此列完全独立于 EXPLAIN 输出中显示的表顺序。这意味着 possible_keys 中的某些键在实践中可能无法与生成的表顺序一起使用。

如果此列为 NULL（或在 JSON 格式的输出中未定义），则表示没有相关的索引。在这种情况下，您可以通过检查 WHERE 子句以查看它是否引用了适合索引的某些列来提高查询的性能。如果是，请创建一个适当的索引并使用 EXPLAIN 再次检查查询。请参阅 第 15.1.9 节“ALTER TABLE 语句”。

要查看表有哪些索引，请使用 SHOW INDEX FROM tbl_name。

key（JSON 名称：key）

key 列指示 MySQL 实际决定使用的键（索引）。如果 MySQL 决定使用 possible_keys 索引之一来查找行，则该索引将列为键值。

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

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

要强制 MySQL 使用或忽略 possible_keys 列中列出的索引，请在查询中使用 FORCE INDEX、USE INDEX 或 IGNORE INDEX。请参阅 第 10.9.4 节“索引提示”。

对于 MyISAM 表，运行 ANALYZE TABLE 有助于优化器选择更好的索引。对于 MyISAM 表，myisamchk --analyze 也有同样的作用。请参阅 第 15.7.3.1 节“ANALYZE TABLE 语句” 和 第 9.6 节“MyISAM 表维护和崩溃恢复”。

key_len（JSON 名称：key_length）

key_len 列指示 MySQL 决定使用的键的长度。key_len 的值使您能够确定 MySQL 实际使用了多部分键的多少部分。如果 key 列显示 NULL，则 key_len 列也显示 NULL。

由于键的存储格式，可以为 NULL 的列的键长度比 NOT NULL 列的键长度大 1。

ref（JSON 名称：ref）

ref 列显示哪些列或常量与 key 列中命名的索引进行比较，以从表中选择行。

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

rows（JSON 名称：rows）

rows 列指示 MySQL 认为它必须检查的行数才能执行查询。

对于 InnoDB 表，此数字是一个估计值，可能并不总是精确的。

filtered（JSON 名称：filtered）

filtered 列指示由表条件过滤的表行的估计百分比。最大值为 100，表示没有过滤任何行。从 100 开始递减的值表示过滤量增加。rows 显示检查的估计行数，rows × filtered 显示与下一个表连接的行数。例如，如果 rows 为 1000，filtered 为 50.00 (50%)，则要与下一个表连接的行数为 1000 × 50% = 500。

Extra（JSON 名称：无）

此列包含有关 MySQL 如何解析查询的附加信息。有关不同值的描述，请参阅 EXPLAIN 额外信息。

没有与 Extra 列对应的单个 JSON 属性；但是，此列中可能出现的值将作为 JSON 属性或 message 属性的文本公开。

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

对于先前表中的每一行组合，都会从此表中读取一行。除了 system 和 const 类型之外，这是最佳连接类型。当连接使用索引的所有部分并且索引是 PRIMARY KEY 或 UNIQUE NOT NULL 索引时，将使用它。

eq_ref 可用于使用 = 运算符比较的索引列。比较值可以是常量，也可以是使用从此表之前读取的表中的列的表达式。在以下示例中，MySQL 可以使用 eq_ref 连接来处理 ref_table

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

对于先前表中的每一行组合，都会从此表中读取所有具有匹配索引值的 ​​行。如果连接仅使用键的最左侧前缀，或者键不是 PRIMARY KEY 或 UNIQUE 索引（换句话说，如果连接无法基于键值选择单个行），则使用 ref。如果使用的键仅匹配几行，则这是一种很好的连接类型。

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

请参阅“第 10.2.1.15 节“IS NULL 优化”。

index_merge

这种连接类型表明使用了索引合并优化。在这种情况下，输出行中的 key 列包含使用的索引列表，key_len 包含使用的索引的最长键部分列表。有关更多信息，请参阅“第 10.2.1.3 节“索引合并优化”。

unique_subquery

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

value IN (SELECT primary_key FROM single_table WHERE some_expr)

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

index_subquery

这种连接类型类似于 unique_subquery。它替换 IN 子查询，但它适用于以下形式的子查询中的非唯一索引

value IN (SELECT key_column FROM single_table WHERE some_expr)

range

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

当使用 =、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN、LIKE 或 IN() 运算符将键列与常量进行比较时，可以使用 range

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

index 连接类型与 ALL 相同，只是扫描了索引树。这以两种方式发生

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

ALL

对先前表中的每一行组合执行全表扫描。如果该表是第一个未标记为 const 的表，这通常不好，并且在所有其他情况下通常非常糟糕。通常，您可以通过添加索引来避免 ALL，这些索引允许根据常量值或先前表中的列值从表中检索行。

Backward index scan（JSON：backward_index_scan）

优化器能够在 InnoDB 表上使用降序索引。与 Using index 一起显示。有关更多信息，请参阅“第 10.3.13 节“降序索引”。

Child of 'table' pushed join@1（JSON：message 文本）

此表在可以下推到 NDB 内核的连接中被引用为 table 的子级。仅适用于启用了下推连接的 NDB 集群。有关更多信息和示例，请参阅 ndb_join_pushdown 服务器系统变量的说明。

const row not found（JSON 属性：const_row_not_found）

对于 SELECT ... FROM tbl_name 等查询，该表为空。

Deleting all rows（JSON 属性：message）

对于 DELETE，某些存储引擎（例如 MyISAM）支持以简单快速的方式删除所有表行的处理程序方法。如果引擎使用此优化，则会显示此 Extra 值。

Distinct（JSON 属性：distinct）

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

FirstMatch(tbl_name)（JSON 属性：first_match）

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

Full scan on NULL key（JSON 属性：message）

当优化器无法使用索引查找访问方法时，这将作为后备策略发生在子查询优化中。

Impossible HAVING（JSON 属性：message）

HAVING 子句始终为假，并且无法选择任何行。

Impossible WHERE（JSON 属性：message）

WHERE 子句始终为假，并且无法选择任何行。

Impossible WHERE noticed after reading const tables（JSON 属性：message）

MySQL 已读取所有 const（和 system）表，并注意到 WHERE 子句始终为假。

LooseScan(m..n)（JSON 属性：message）

使用半连接 LooseScan 策略。m 和 n 是键部分号。

No matching min/max row（JSON 属性：message）

没有行满足 SELECT MIN(...) FROM ... WHERE condition 等查询的条件。

no matching row in const table（JSON 属性：message）

对于具有连接的查询，存在一个空表或一个没有行满足唯一索引条件的表。

No matching rows after partition pruning（JSON 属性：message）

对于 DELETE 或 UPDATE，优化器在分区修剪后没有找到要删除或更新的内容。它的含义类似于 SELECT 语句的 Impossible WHERE。

No tables used（JSON 属性：message）

该查询没有 FROM 子句，或者有一个 FROM DUAL 子句。

对于 INSERT 或 REPLACE 语句，当没有 SELECT 部分时，EXPLAIN 会显示此值。例如，它会出现在 EXPLAIN INSERT INTO t VALUES(10) 中，因为它等同于 EXPLAIN INSERT INTO t SELECT 10 FROM DUAL。

不存在（JSON 属性：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 中实际匹配多少行。

这也可以表明，形式为 NOT IN (subquery) 或 NOT EXISTS (subquery) 的 WHERE 条件已在内部转换为反连接。这将删除子查询并将其表引入最顶层查询的计划中，从而改进了成本规划。通过合并半连接和反连接，优化器可以更自由地重新排列执行计划中的表，在某些情况下可以生成更快的计划。

您可以通过检查执行 EXPLAIN 后 SHOW WARNINGS 的 Message 列或 EXPLAIN FORMAT=TREE 的输出，查看何时对给定查询执行反连接转换。

计划尚未准备好（JSON 属性：无）

当优化器尚未完成为在命名连接中执行的语句创建执行计划时，使用 EXPLAIN FOR CONNECTION 会出现此值。如果执行计划输出包含多行，则根据优化器确定完整执行计划的进度，其中任何一行或所有行都可能具有此 Extra 值。

已为每条记录检查范围（索引映射：N）（JSON 属性：message）

MySQL 没有找到要使用的良好索引，但发现知道前面表中的列值后，可以使用某些索引。对于前面表中的每个行组合，MySQL 都会检查是否可以使用 range 或 index_merge 访问方法来检索行。这并不是很快，但比完全不使用索引执行连接要快。适用性标准如 第 10.2.1.2 节“范围优化” 和 第 10.2.1.3 节“索引合并优化” 中所述，但前面表的所有列值都是已知的并被视为常量。

索引从 1 开始编号，顺序与 SHOW INDEX 为表显示的顺序相同。索引映射值 N 是一个位掩码值，指示哪些索引是候选项。例如，值 0x19（二进制 11001）表示索引 1、4 和 5 被考虑。

递归（JSON 属性：recursive）

这表明该行适用于递归公共表表达式的递归 SELECT 部分。请参阅 第 15.2.20 节“WITH（公共表表达式）”。

重新实例化（JSON 属性：rematerialize）

在表 T 的 EXPLAIN 行中显示 Rematerialize (X,...)，其中 X 是任何在读取 T 的新行时触发其重新实例化的横向派生表。例如

SELECT
  ...
FROM
  t,
  LATERAL (derived table that refers to t) AS dt
...

每次顶级查询处理 t 的新行时，都会重新实例化派生表的内容以使其保持最新。

已扫描 N 个数据库（JSON 属性：message）

这指示服务器在处理 INFORMATION_SCHEMA 表的查询时执行了多少次目录扫描，如 第 10.2.3 节“优化 INFORMATION_SCHEMA 查询” 中所述。N 的值可以是 0、1 或 all。

选择表已优化掉（JSON 属性：message）

优化器确定 1) 最多应返回一行，以及 2) 要生成此行，必须读取一组确定的行。当要在优化阶段读取的行可以在优化阶段读取时（例如，通过读取索引行），则在查询执行期间无需读取任何表。

当查询被隐式分组（包含聚合函数但没有 GROUP BY 子句）时，第一个条件得到满足。当每个使用的索引执行一行查找时，第二个条件得到满足。读取的索引数决定了要读取的行数。

考虑以下隐式分组查询

SELECT MIN(c1), MIN(c2) FROM t1;

假设可以通过读取一行索引行来检索 MIN(c1)，并且可以通过从不同索引读取一行来检索 MIN(c2)。也就是说，对于每一列 c1 和 c2，都存在一个索引，其中该列是索引的第一列。在这种情况下，将返回一行，该行是通过读取两行确定的行生成的。

如果要读取的行不是确定的，则不会出现此 Extra 值。考虑此查询

SELECT MIN(c2) FROM t1 WHERE c1 <= 10;

假设 (c1, c2) 是一个覆盖索引。使用此索引，必须扫描 c1 <= 10 的所有行以找到最小 c2 值。相反，考虑此查询

SELECT MIN(c2) FROM t1 WHERE c1 = 10;

在这种情况下，c1 = 10 的第一行索引包含最小 c2 值。只需读取一行即可生成返回的行。

对于为每个表维护精确行计数的存储引擎（例如 MyISAM，而不是 InnoDB），对于 COUNT(*) 查询，如果缺少 WHERE 子句或 WHERE 子句始终为真并且没有 GROUP BY 子句，则可能会出现此 Extra 值。（这是隐式分组查询的一个实例，其中存储引擎会影响是否可以读取确定数量的行。）

Skip_open_table、Open_frm_only、Open_full_table（JSON 属性：message）

这些值指示适用于 INFORMATION_SCHEMA 表的查询的文件打开优化。

Start temporary、End temporary（JSON 属性：message）

这表示半连接重复数据删除策略使用临时表。

未找到唯一行（JSON 属性：message）

对于 SELECT ... FROM tbl_name 等查询，没有行满足表上的 UNIQUE 索引或 PRIMARY KEY 的条件。

正在使用文件排序（JSON 属性：using_filesort）

MySQL 必须执行额外的传递才能找出如何按排序顺序检索行。排序是通过根据连接类型遍历所有行并存储所有匹配 WHERE 子句的行的排序键和指向该行的指针来完成的。然后对键进行排序，并按排序顺序检索行。请参阅 第 10.2.1.16 节“ORDER BY 优化”。

正在使用索引（JSON 属性：using_index）

仅使用索引树中的信息从表中检索列信息，而无需执行额外的查找来读取实际的行。当查询仅使用属于单个索引的列时，可以使用此策略。

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

有关使用的任何覆盖索引的信息，请参见 EXPLAIN FORMAT=TRADITIONAL 和 EXPLAIN FORMAT=JSON。它也显示在 EXPLAIN FORMAT=TREE 中。

正在使用索引条件（JSON 属性：using_index_condition）

通过访问索引元组并首先对其进行测试以确定是否读取完整的表行来读取表。这样，索引信息用于延迟（“下推”）读取完整的表行，除非有必要。请参阅 第 10.2.1.6 节“索引条件下推优化”。

正在使用索引进行分组（JSON 属性：using_index_for_group_by）

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

正在使用索引进行跳跃扫描（JSON 属性：using_index_for_skip_scan）

指示正在使用跳跃扫描访问方法。请参阅 跳跃扫描范围访问方法。

正在使用连接缓冲区（块嵌套循环）、正在使用连接缓冲区（批处理键访问）、正在使用连接缓冲区（哈希连接）（JSON 属性：using_join_buffer）

来自先前连接的表被分批读入连接缓冲区，然后从缓冲区中使用它们的行来执行与当前表的连接。(Block Nested Loop) 表示使用块嵌套循环算法，(Batched Key Access) 表示使用批处理键访问算法，(hash join) 表示使用哈希连接。也就是说，来自 EXPLAIN 输出的上一行的表的键被缓冲，并且匹配的行从出现 Using join buffer 的行所表示的表中分批获取。

在 JSON 格式的输出中，using_join_buffer 的值始终是 Block Nested Loop、Batched Key Access 或 hash join 之一。

有关哈希连接的更多信息，请参见 第 10.2.1.4 节“哈希连接优化”。

有关批处理键访问算法的信息，请参见 批处理键访问连接。

Using MRR（JSON 属性：message）

使用多范围读取优化策略读取表。请参见 第 10.2.1.11 节“多范围读取优化”。

Using sort_union(...)、Using union(...)、Using intersect(...)（JSON 属性：message）

这些指示了显示如何为 index_merge 连接类型合并索引扫描的特定算法。请参见 第 10.2.1.3 节“索引合并优化”。

Using temporary（JSON 属性：using_temporary_table）

为了解析查询，MySQL 需要创建一个临时表来保存结果。如果查询包含列出不同列的 GROUP BY 和 ORDER BY 子句，通常会发生这种情况。

Using where（JSON 属性：attached_condition）

WHERE 子句用于限制与下一个表匹配或发送到客户端的行。除非您特别打算从表中获取或检查所有行，否则如果 Extra 值不是 Using where 并且表连接类型是 ALL 或 index，则您的查询中可能有问题。

Using where 在 JSON 格式的输出中没有直接的对应项；attached_condition 属性包含使用的任何 WHERE 条件。

Using where with pushed condition（JSON 属性：message）

此项仅适用于 NDB 表。这意味着 NDB 集群正在使用条件下推优化来提高非索引列和常量之间直接比较的效率。在这种情况下，条件被““下推””到集群的数据节点，并在所有数据节点上同时进行评估。这消除了通过网络发送不匹配行的需要，并且可以使此类查询的速度比可以使用但未使用条件下推的情况快 5 到 10 倍。有关更多信息，请参见 第 10.2.1.5 节“引擎条件下推优化”。

Zero limit（JSON 属性：message）

查询有一个 LIMIT 0 子句，并且无法选择任何行。

要比较的列已声明如下。

这些表具有以下索引。

tt.ActualPC 值不是均匀分布的。