MySQL EXPLAIN

• Child of 'table' pushed join@1此表被引用为table可以下推到NDB内核的联接中的子代 。仅当启用了下推连接时，才适用于MySQL NDB Cluster 7.2及更高版本。有关ndb_join_pushdown更多信息和示例，请参阅 服务器系统变量的说明。
• const row not found对于诸如此类的查询，该表为空。 SELECT ... FROM tbl_name
• DistinctMySQL正在寻找不同的值，因此它在找到第一个匹配行后停止为当前行组合搜索更多行。
• Full scan on NULL key当优化程序无法使用索引查找访问方法时，子查询优化会作为回退策略发生这种情况。
• Impossible HAVING该HAVING子句始终为false，不能选择任何行。
• Impossible WHERE该WHERE子句始终为false，不能选择任何行。
• Impossible WHERE noticed after reading const tablesMySQL已经读取了所有 const（和 system）表，并注意到该WHERE子句始终为false。
• No matching min/max row没有行满足查询的条件，例如 。 SELECT MIN(...) FROM ... WHERE condition
• no matching row in const table对于具有连接的查询，有一个空表或没有满足唯一索引条件的行的表。
• No tables used查询没有FROM子句，或者有 FROM DUAL子句。
• Not existsMySQL能够对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并查找行 。如果MySQL找到匹配的行 ，则它知道 永远不会 ，并且不会扫描具有相同值的其余行。换句话说，对于每一行，MySQL只需要进行一次查找，而不管实际匹配的行数。 t2t1.idt2t2.idNULLt2idt1t2t2
• Range checked for each record (index map: N)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这表示服务器在处理INFORMATION_SCHEMA表查询时执行的目录扫描次数 ，如第8.2.3节“优化INFORMATION_SCHEMA查询”中所述。值N可以是0,1或all。
• Select tables optimized away优化器确定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）的存储引擎，对于缺少该子句或始终为true且没有 子句的查询，Extra 可能会出现此值。（这是隐式分组查询的实例，其中存储引擎会影响是否可以读取确定数量的行。） COUNT(*)WHEREGROUP BY
• Skip_open_table， Open_frm_only， Open_full_table这些值表示适用于INFORMATION_SCHEMA 表查询的文件打开优化，如 第8.2.3节“优化INFORMATION_SCHEMA查询”中所述。
  • Skip_open_table：表文件不需要打开。通过扫描数据库目录，该信息已在查询中可用。
  • Open_frm_only：只.frm需要打开表的 文件。
  • Open_full_table：未经优化的信息查找。的.frm， .MYD和 .MYI文件必须被打开。
• unique row not found对于诸如的查询，没有行满足 索引或表的条件。 SELECT ... FROM tbl_nameUNIQUEPRIMARY KEY
• Using filesortMySQL必须执行额外的传递以找出如何按排序顺序检索行。排序是通过根据连接类型遍历所有行并将排序键和指针存储到与该WHERE子句匹配的所有行的行来完成的。然后对键进行排序，并按排序顺序检索行。请参见 第8.2.1.10节“ORDER BY Optimization”。
• Using index仅使用索引树中的信息从表中检索列信息，而不必执行额外的搜索以读取实际行。当查询仅使用属于单个索引的列时，可以使用此策略。对于InnoDB具有用户定义的聚簇索引的表，即使列中Using index不存在 该索引，也可以使用该索引Extra。这样的话，如果 type是 index和 key是PRIMARY。
• Using index for group-by与Using index表访问方法类似，Using index for group-by 表示MySQL找到了一个索引，可用于检索GROUP BY或 DISTINCT查询的所有列，而无需对实际表进行任何额外的磁盘访问。此外，索引以最有效的方式使用，因此对于每个组，只读取少数索引条目。有关详细信息，请参见 第8.2.1.11节“GROUP BY优化”。
• Using join buffer将早期联接中的表分成几部分读入连接缓冲区，然后从缓冲区中使用它们的行来执行与当前表的连接。
• Using sort_union(...)，Using union(...)，Using intersect(...)这些指示特定算法显示如何为index_merge连接类型合并索引扫描 。请参见第8.2.1.3节“索引合并优化”。
• Using temporary要解析查询，MySQL需要创建一个临时表来保存结果。如果查询包含以不同方式列出列的GROUP BY和 ORDER BY子句，则通常会发生这种情况。
• Using where甲WHERE子句用于限制匹配哪些行针对下一个表或发送到客户端。除非您特意打算从表中获取或检查所有行，否则如果Extra值不是 Using where并且表连接类型为ALL或者 ，则 查询中可能出现错误index。即使您正在为WHERE 子句的所有部分使用索引，您也可以查看Using where列是否可以NULL。
• Using where with pushed condition此产品适用于NDB 表只。这意味着NDB Cluster正在使用条件下推优化来提高非索引列和常量之间直接比较的效率。在这种情况下，条件被“ 下推 ”到集群的数据节点，并在所有数据节点上同时进行评估。这消除了通过网络发送不匹配行的需要，并且可以在可以但不使用条件下推的情况下将这种查询加速5到10倍。有关更多信息，请参阅 第8.2.1.4节“发动机状态下推优化”。

EXPLAIN输出解释

EXPLAIN SELECT tt.TicketNumber, tt.TimeIn,
               tt.ProjectReference, tt.EstimatedShipDate,
               tt.ActualShipDate, tt.ClientID,
               tt.ServiceCodes, tt.RepetitiveID,
               tt.CurrentProcess, tt.CurrentDPPerson,
               tt.RecordVolume, tt.DPPrinted, et.COUNTRY,
               et_1.COUNTRY, do.CUSTNAME
        FROM tt, et, et AS et_1, do
        WHERE tt.SubmitTime IS NULL
          AND tt.ActualPC = et.EMPLOYID
          AND tt.AssignedPC = et_1.EMPLOYID
          AND tt.ClientID = do.CUSTNMBR;

table type possible_keys key  key_len ref  rows  Extra
et    ALL  PRIMARY       NULL NULL    NULL 74
do    ALL  PRIMARY       NULL NULL    NULL 2135
et_1  ALL  PRIMARY       NULL NULL    NULL 74
tt    ALL  AssignedPC,   NULL NULL    NULL 3872
           ClientID,
           ActualPC
      Range checked for each record (index map: 0x23)

mysql> ALTER TABLE tt MODIFY ActualPC VARCHAR(15);

table type   possible_keys key     key_len ref         rows    Extra
tt    ALL    AssignedPC,   NULL    NULL    NULL        3872    Using
             ClientID,                                         where
             ActualPC
do    ALL    PRIMARY       NULL    NULL    NULL        2135
      Range checked for each record (index map: 0x1)
et_1  ALL    PRIMARY       NULL    NULL    NULL        74
      Range checked for each record (index map: 0x1)
et    eq_ref PRIMARY       PRIMARY 15      tt.ActualPC 1

mysql> ALTER TABLE tt MODIFY AssignedPC VARCHAR(15),
                      MODIFY ClientID   VARCHAR(15);

table type   possible_keys key      key_len ref           rows Extra
et    ALL    PRIMARY       NULL     NULL    NULL          74
tt    ref    AssignedPC,   ActualPC 15      et.EMPLOYID   52   Using
             ClientID,                                         where
             ActualPC
et_1  eq_ref PRIMARY       PRIMARY  15      tt.AssignedPC 1
do    eq_ref PRIMARY       PRIMARY  15      tt.ClientID   1

mysql> ANALYZE TABLE tt;

table type   possible_keys key     key_len ref           rows Extra
tt    ALL    AssignedPC    NULL    NULL    NULL          3872 Using
             ClientID,                                        where
             ActualPC
et    eq_ref PRIMARY       PRIMARY 15      tt.ActualPC   1
et_1  eq_ref PRIMARY       PRIMARY 15      tt.AssignedPC 1
do    eq_ref PRIMARY       PRIMARY 15      tt.ClientID   1