MySQL：為什麼帶有子查詢的查詢比單個查詢快得多？

我最近對我的數據庫進行了一些查詢

第一個查詢：

 SELECT `table`.*
 FROM (`table`)
 WHERE table.id in(27172172,[...bunch of ids...],27171770)
 ORDER BY field (`table`.`id`, 27172172,27172168,[...bunch of ids...],27171770);
 [...result...]

一組 25 行**（0.22 秒）**

 explain:
 +----+-------------+-------------+-------+---------------+---------+---------+------+------+-----------------------------+
 | id | select_type | table       | type  | possible_keys | key     | key_len | ref  | rows | Extra                       |
 +----+-------------+-------------+-------+---------------+---------+---------+------+------+-----------------------------+
 |  1 | SIMPLE      | table       | range | PRIMARY       | PRIMARY | 4       | NULL |   25 | Using where; Using filesort |
 +----+-------------+-------------+-------+---------------+---------+---------+------+------+-----------------------------+

第二個查詢：

 SELECT * FROM (SELECT `table`.* 
   FROM (`table`) 
   WHERE table.id in(27172172,27172168,[...bunch of ids...],27171770)
 ) as x  
 ORDER BY field (`id`,27172172,27172168,[...bunch of ids...],27171770); 
 [...result...]

一組 25 行**（0.00 秒）**

 explain:
 +----+-------------+-------------+-------+---------------+---------+---------+------+------+----------------+
 | id | select_type | table       | type  | possible_keys | key     | key_len | ref  | rows | Extra          |
 +----+-------------+-------------+-------+---------------+---------+---------+------+------+----------------+
 |  1 | PRIMARY     | <derived2>  | ALL   | NULL          | NULL    | NULL    | NULL |   25 | Using filesort |
 |  2 | DERIVED     | table       | range | PRIMARY       | PRIMARY | 4       | NULL |   25 | Using where    |

 +----+-------------+-------------+-------+---------------+---------+---------+------+------+----------------+

我可以清楚地看到更複雜的查詢比簡單的查詢要快得多**。**選擇“in”，但無順序執行在 0.00 秒內。這種現像不僅在“order by field”查詢中可見，而且在幾乎所有比“select * from table where id=N”更複雜的查詢中都可以看到percona.com上有一篇文章（http://www.percona.com/ blog/2010/03/18/when-the-subselect-runs-faster/）描述了類似的情況，但這種解釋並不完全適合這裡。所以我的問題很簡單：

1）為什麼用子查詢查詢比單查詢更有效？

2）為什麼mysql優化器不能自己做這樣的優化。

3）我的錯誤在哪裡？查詢錯誤？錯誤的mysql配置？或者也許這是完全可以預料的，並且“子查詢技巧”在世界範圍內被廣泛使用？

額外資訊：表是 innodb，目前行數是 26205445，所以它很大。Id 是該表中的主鍵。Mysql：版本 5.5.34-32.0-log for Linux on x86_64（Percona Server (GPL)，Release 32.0） 伺服器：基於 debian，ssd 磁碟，128GB 記憶體。

我升級到了 percona mysql 5.6，它解決了一個問題。兩種類型的查詢執行相同。幸運的是 - 同樣快。

引用自：https://dba.stackexchange.com/questions/81890