MySQL执行计划显示与执行过程不符合一例

一 建表和现象的过程如下

CREATE TABLE t1 (id1 INT, a1 INT, b1 INT, PRIMARY KEY(id1));
CREATE TABLE t3 (id3 INT UNIQUE, a3 INT, b3 INT);

INSERT INTO t1 VALUES (1, 1, NULL);
INSERT INTO t3 VALUES (1, 1, NULL);

mysql> select * from (select * from t1 where id1 =(select id3 from t3 where id3=1)) t;
+-----+------+------+
| id1 | a1 | b1 |
+-----+------+------+
| 1 | 1 | NULL |
+-----+------+------+
1 row in set (0.01 sec)

mysql> explain extended select * from (select * from t1 where id1=(select id3 from t3 where id3=1)) t;
+----+-------------+------------+--------+---------------+---------+---------+-------+------+----------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+--------+---------------+---------+---------+-------+------+----------+-------------+
| 1 | PRIMARY | <derived2> | system | NULL | NULL | NULL | NULL | 1 | 100.00 | NULL |
| 2 | DERIVED | t1 | const | PRIMARY | PRIMARY | 4 | const | 1 | 100.00 | NULL |
| 3 | SUBQUERY | t3 | const | id3 | id3 | 5 | const | 1 | 100.00 | Using index |
+----+-------------+------------+--------+---------------+---------+---------+-------+------+----------+-------------+
3 rows in set, 1 warning (0.00 sec)

mysql> show warnings;
+-------+------+-----------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+-----------------------------------------------------------------------+
| Note | 1003 | /* select#1 */ select ‘1‘ AS `id1`,‘1‘ AS `a1`,NULL AS `b1` from dual |
+-------+------+-----------------------------------------------------------------------+
1 row in set (0.00 sec)



二 分析:
首先, 察看执行计划:
1 id值为1的select_type值为PRIMARY, 这是一个‘<derived2>‘表,表示子查询出现在FROM子句中，且本行的内容是一个类似“壳”一样的并无多大实质意义的‘虚表’，‘<derived2>‘中的数字2来自于下一行id为2的结果。而别名为t的子查询，确实出现在最外层的FROM中。
2 id值为2的select_type值为DERIVED，表示这是一个被驱动的表(被驱动的FROM子句中的子查询). 
3 id值为3的select_type值为SUBQUERY，表示嵌套中的第二个在t3表上的子查询，没有被优化为其他类型（优化可如子查询被消除后转为内连接）。


其次，察看警告信息：
1 FROM子句后的表变为了‘dual’这一虚表，t1和t2全部消失。为什么？
2 MySQL在优化的过程中，利用等式的性质，推知了：
  2.1 id1=id3=1
  2.2 查询语句从逻辑推理上，就可以变形为：select * from t1 where id1=1
      此时，子查询其实被消除了，但是执行计划中没有体现这一点，这是执行计划错误之处。
  2.3 进一步，t1表上id1列是主键，所以根据索引，可以查知*对应的目标列的值：这样，逻辑推理上，就可以变形为：
      select ‘1‘ AS `id1`,‘1‘ AS `a1`,NULL AS `b1` from t1 where id1=1
  2.4 因为目标列的值已经能够在优化的过程中得知，所以FROM子句中的表，可被标识为“常量表”。
3 于是，在显示查询执行计划的后期（explain命令后期），代码中有个判断：如果表全部是常量表且已经是“被优化了的（optimized_away）”则把FROM子句中的表对象，用“dual”替换。这就是警告中为什么会出现“from dual”的原因。


再次，执行计划和警告信息显示存在不一致，那么，MySQL在执行的时候，是按照谁来执行呢？
这点可以通过跟踪代码进行分析。
执行过程如下：
1 优化阶段：即生成执行计划阶段
  MySQL在优化阶段的过程，就如执行计划显示的结果一样，对各个子句进行着执行计划显示的过程，先是因为FROM子句中的子查询执行id为1的过程，然后是对被驱动的id为2的优化，在没有结束id为2的优化的过程中，发现id为2的子句是子查询，就嵌套调用去优化子查询，于是引发了等式化简等过程。
  在运用各种技术做各种化简的过程中，一些值或结果已经得知，顺带即完成了一些求解的工作。
  这也说明一个问题：有的朋友问id间的序号表明了一个什么样的执行次序？因为嵌套的关系，首先启动的是id值小的，在id值为小的执行过程中，接着又启动了id值为大的查询子句，所以，最先执行完毕的，是id值大者；最先执行的，是id值小者。
2 执行阶段： 
  已经知道是一个常量求解，且结果在优化过程中得知，直接输出。
  这也解释了警告信息中得到的是“from dual”，与执行过程的含义，相符。即：执行阶段，查询计划表明的过程已经结束了。


三 补充说明


mysql>  explain extended select * from (select * from t1 where id1 in (select id3 from t3 where id3=1)) t；
    -> ;
+----+-------------+------------+--------+---------------+---------+---------+-------+------+----------+-------------+
| id | select_type | table      | type   | possible_keys | key     | key_len | ref   | rows | filtered | Extra       |
+----+-------------+------------+--------+---------------+---------+---------+-------+------+----------+-------------+
|  1 | PRIMARY     | <derived2> | system | NULL          | NULL    | NULL    | NULL  |    1 |   100.00 | NULL        |
|  2 | DERIVED     | t1         | const  | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL        |
|  2 | DERIVED     | t3         | const  | id3           | id3     | 5       | const |    1 |   100.00 | Using index |
+----+-------------+------------+--------+---------------+---------+---------+-------+------+----------+-------------+
3 rows in set, 1 warning (49.53 sec)


mysql> show warnings;
+-------+------+-----------------------------------------------------------------------+
| Level | Code | Message                                                               |
+-------+------+-----------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select ‘1‘ AS `id1`,‘1‘ AS `a1`,NULL AS `b1` from dual |
+-------+------+-----------------------------------------------------------------------+
1 row in set (0.00 sec)


"标题三"中和"标题一"中的SQL差别在于嵌套的子查询的形式是等号还是IN。


而IN的形式，被MySQL识别优化了标识子查询未“DERIVED ”了，这是MySQL从形式上目前只支持IN形式的子查询优化的优化，对于等号这样的形式，不支持。但是，从等式性质上，最终对"标题一"中的SQL进行了优化。


参考：


http://blog.163.com/li_hx/blog/static/18399141320146219354154/


MySQL执行计划显示与执行过程不符合一例
				


				
时间： 2024-08-28 17:40:46 

		


		


	

	
	

		


		
MySQL执行计划显示与执行过程不符合一例的相关文章


								

		

			

                MySQL执行计划显示与执行过程不符合
			

		

		

									

				一 建表和现象的过程如下 CREATE TABLE t1 (id1 INT, a1 INT, b1 INT, PRIMARY KEY(id1));CREATE TABLE t3 (id3 INT UNIQUE, a3 INT, b3 INT); INSERT INTO t1 VALUES (1, 1, NULL);INSERT INTO t3 VALUES (1, 1, NULL); mysql> select * from (select * from t1 where id1 =(selec			

		

	

				

		

			

                ORACLE实际执行计划与预估执行计划不一致性能优化案例
			

		

		

									

				  在一台ORACLE服务器上做巡检时,使用下面SQL找出DISK_READ最高的TOP SQL分析时,分析过程中,有一条SQL语句的一些反常现象,让人觉得很奇怪: SELECT SQL_ID,        SQL_TEXT,        DISK_READS,        BUFFER_GETS,        PARSING_SCHEMA_NAME,        EXECUTIONS FROM   V$SQLAREA ORDER  BY DISK_READS DESC; 在SQL D			

		

	

				

		

			

                xplan.sql(本脚本获取执行计划显示执行顺序)
			

		

		

									

				-- ---------------------------------------------------------------------------------------------- -- -- Script: xplan.sql -- -- Author: Adrian Billington -- -- -- Description: Creates a package named XPLAN as a wrapper over DBMS_XPLAN. Provides acces			

		

	

				

		

			

                在MySQL中使用explain查询SQL的执行计划
			

		

		

									

				1.什么是MySQL执行计划 要对执行计划有个比较好的理解,需要先对MySQL的基础结构及查询基本原理有简单的了解. MySQL本身的功能架构分为三个部分,分别是 应用层.逻辑层.物理层,不只是MySQL ,其他大多数数据库产品都是按这种架构来进行划分的. 应用层,主要负责与客户端进行交互,建立链接,记住链接状态,返回数据,响应请求,这一层是和客户端打交道的. 逻辑层,主要负责查询处理.事务管理等其他数据库功能处理,以查询为例. 首先接收到查询SQL之后,数据库会立即分配一个线程对其进行处理,第			

		

	

				

		

			

                MySQL执行计划 EXPLAIN参数
			

		

		

									

				MySQL执行计划参数详解 转http://www.jianshu.com/p/7134286b3a09 MySQL数据库中,在SELECT查询语句前边加上“EXPLAIN”或者“DESC”关键字,即可查看该查询语句的执行计划,分析执行计划是优化慢查询的重要手段.如: EXPLAIN SELECT * FROM school; DESC SELECT * FROM school; 执行结果: 执行计划参数.png 接下来对这10个参数进行简单解释: 1.id:在整个查询中SELECT的位置: 2			

		

	

				

		

			

                DRDS分布式SQL引擎—执行计划介绍
			

		

		

									

				摘要: 本文着重介绍 DRDS 执行计划中各个操作符的含义,以便用户通过查询计划了解 SQL 执行流程,从而有针对性的调优 SQL. DRDS分布式SQL引擎 - 执行计划介绍 前言 数据库系统中,执行计划是对 SQL 如何执行的形式化表示,往往由若干关系操作符构成,用户可以通过对应的 EXPLAIN 命令查看,并通过执行计划大致了解 SQL 的执行过程和执行方式,如全表扫描还是索引扫描,归并连接还是哈希连接等.执行计划可以为用户进行 SQL 调优提供重要依据. DRDS 执行计划 与多数数据库			

		

	

				

		

			

                执行计划的生成
			

		

		

									

				SQL Server使用许多技术来优化资源消耗: 基于语法的查询优化: 无用计划匹配以避免对简单查询的深度优化: 根据当前分布统计的索引和连接策略: 多阶段的查询优化以控制优化开销: 执行计划缓冲以避免重新生成执行计划: 以上技术按以下顺序执行: 解析器: 代数化器: 查询优化器: 执行计划生成,缓冲和hash计划生成: 查询执行: 其执行顺序如下: 一.解析器(parser) 当查询被提交时,SQL Server将它传递给关系引擎中的解析器. 关系引擎-负责解析.名称和类型解析.优化和按照查询			

		

	

				

		

			

                06 执行计划
			

		

		

									

				本章提要-------------------------------------------如何设置, 来获取执行计划如何读懂执行计划-------------------------------------------执行计划描述了SQL引擎为执行SQL语句进行的操作. 在任何时候, 要处理执行计划, 需以下三步, 获取, 解释, 判定效率. 6.1 获取执行计划    获取的办法:    1) 执行SQL语句EXPLAIN PLAN, 查询结果输出表    2) 查看动态视图    3)			

		

	

				

		

			

                Oracle SQL执行计划基线总结（SQL Plan Baseline）
			

		

		

									

				一.基础概念 Oracle 11g开始,提供了一种新的固定执行计划的方法,即SQL plan baseline,中文名SQL执行计划基线(简称基线),可以认为是OUTLINE(大纲)或者SQL PROFILE的改进版本,基本上它的主要作用可以归纳为如下两个: 1.稳定给定SQL语句的执行计划,防止执行环境或对象统计信息等等因子的改变对SQL语句的执行计划产生影响! 2.减少数据库中出现SQL语句性能退化的概率,理论上不允许一条语句切换到一个比已经执行过的执行计划慢很多的新的执行计划上! 注意: