一 建表和現象的過程如下

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=5)) 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 '5' AS `id1`,'5' AS `a1`,NULL AS `b1` from dual |
+-------+------+-----------------------------------------------------------------------+
1 row in set (0.00 sec)

"標題三"中和"標題一"中的SQL差別在於巢狀的子查詢的形式是等號還是IN。

而IN的形式，被MySQL識別優化了標識子查詢未“DERIVED ”了，這是MySQL從形式上目前只支援IN形式的子查詢優化的優化，對於等號這樣的形式，不支援。但是，從等式性質上，最終對"標題一"中的SQL進行了優化。