問題描述

explain select * from ecs_ad where ad_id =1 or ad_id = 3;+----+-------------+--------+-------+---------------+---------+---------+------+------+-----------------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+--------+-------+---------------+---------+---------+------+------+-----------------------+| 1 | SIMPLE | ecs_ad | range | PRIMARY | PRIMARY | 2 | NULL | 2 | Using index condition |+----+-------------+--------+-------+---------------+---------+---------+------+------+-----------------------+1 row in set

這是union all的

explain select * from ecs_ad where ad_id = 4 union all select * from ecs_ad where ad_id = 3;+------+--------------+------------+-------+---------------+---------+---------+-------+------+-----------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+------+--------------+------------+-------+---------------+---------+---------+-------+------+-----------------+| 1 | PRIMARY | ecs_ad | const | PRIMARY | PRIMARY | 2 | const | 1 | NULL || 2 | UNION| ecs_ad | const | PRIMARY | PRIMARY | 2 | const | 1 | NULL || NULL | UNION RESULT | <union1,2> | ALL | NULL | NULL | NULL | NULL | NULL | Using temporary |+------+--------------+------------+-------+---------------+---------+---------+-------+------+-----------------+3 rows in set

問題解答

首先，這兩個查詢性能差距應該不大。因為 ad_id 列是主鍵.

根據 type 列分析：or 查詢，type：rangeunion all 查詢：type：const / const / ALL

首先可以確認的是，const 要優于 range.const 也是因為 ad_id 為主鍵.

但是 union all 做了三次操作，兩次主鍵或者唯一索引查詢 type:const，但最后組合到一起時 type:ALLtype:ALL 本身性能比 range 還要差

從 Type 看，or 查詢性能應該更好.

Extra 分析or 查詢：Using index conditionunion all 查詢：NULL / NULL / Using temporary

Using index condition 為 MySQL 5.6 版本以后新添加的特性，索引條件推送。

首先說一下沒有索引條件推送時候的處理流程：

優化器沒有使用ICP時，數據訪問和提取的過程如下：

1) 當storage engine讀取下一行時，首先讀取索引元組（index tuple），然后使用索引元組在基表中（base table）定位和讀取整行數據。2) sever層評估where條件，如果該行數據滿足where條件則使用，否則丟棄。3) 執行1），直到最后一行數據。

當存在索引條件推送時候的處理流程：

優化器使用ICP時，server層將會把能夠通過使用索引進行評估的where條件下推到storage engine層。數據訪問和提取過程如下：

1) storage engine從索引中讀取下一條索引元組。2) storage engine使用索引元組評估下推的索引條件。如果沒有滿足wehere條件，storage engine將會處理下一條索引元組（回到上一步）。只有當索引元組滿足下推的索引條件的時候，才會繼續去基表中讀取數據。3) 如果滿足下推的索引條件，storage engine通過索引元組定位基表的行和讀取整行數據并返回給server層。4) server層評估沒有被下推到storage engine層的where條件，如果該行數據滿足where條件則使用，否則丟棄。

簡單來說，沒有 ICP 時，存儲引擎返回所有滿足條件的整行數據，在 service 層進行 where 條件過濾。有 ICP 時，where 條件下推到存儲引擎層，存儲引擎直接返回滿足條件的數據。性能自然提高很多。

對于 ICP 的相關介紹，可以查看這里

而 Using temporary 表示隱式臨時表，意思是 MySQL 會在產生一個臨時表，存放中間數據。因為 union all 是分開處理，最后合并的關系。從 Extra 看，也應該是 or 查詢性能更高。

綜合來看：OR 查詢的性能應該有優于 UNION ALL .

由于所有查詢性能都隨著數據量增大而變化，以上分析只是單看題主所貼的 Explain 分析結果。也并不是說 OR 在所有情況下都優于 UNION ALL。

以上為個人意見，如有錯誤，請指正。

這兩個語句，無區別。一般or連接兩個不同字段，無法使用索引的時候，性能會比較差，不如union，可以嘗試修改。