MySQL中使用or、in與union all在查詢命令下的效率對比

OR、in和union all 查詢效率到底哪個快？
網上很多的聲音都是說union all 快于 or、in，因為or、in會導致全表掃描，他們給出了很多的實例。
但真的union all真的快于or、in？

EXPLAIN SELECT * from employees where employees.first_NAME ='Georgi' UNION ALL SELECT * from employees where employees.first_NAME ='Bezalel'

這條語句執行結果481條，執行時間為0.35s

PRIMARY employees ALL 300141 Using whereUNION employees ALL 300141 Using where UNION RESULT <union1,2> ALL explain SELECT * FROM employees WHERE employees.first_name IN ('Georgi','Bezalel')

這條語句的執行結果時間為0.186s

SIMPLE  employees  ALL  300141  Using whereexplain SELECT * FROM employees WHERE employees.first_name ='Georgi' or employees.first_name='Bezalel'

這條語句的執行結果和in的結果差不多

難道是網上的說法有誤？難道和索引有關？在firstname上建立了一個索引

重新執行

union的執行執行計劃如下，執行時間為0.004s

PRIMARY  employees  ref  index_firstname  index_firstname  44  const  253  Using whereUNION  employees  ref  index_firstname  index_firstname  44  const  228  Using whereUNION RESULT  <union1,2>  ALL

in的執行計劃如下，執行時間也為0.004s

SIMPLE  employees  range  index_firstname  index_firstname  44  481  Using where

or的執行計劃如下，執行時間也為0.004s

SIMPLE  employees  range  index_firstname  index_firstname  44  481  Using where

感覺性能差不多啊。但是注意執行計劃中的type，ref要好于range哦(ref為非唯一性索引掃描，range為索引范圍掃描）
突然感覺好像和網上說的差不多了，但是第一個語句走了兩個ref掃描會不會效率比走一次range的掃描低啊。

要不我再試試主鍵，這個是唯一的，會不會和網上的效果一直呢？

EXPLAIN SELECT * FROM employees WHERE employees.EMP_NO=100001 UNION ALL SELECT * FROM employees WHERE employees.EMP_NO=101100

union的執行計劃如下

PRIMARY  employees  const  PRIMARY  PRIMARY  4  const  1  UNION  employees  const  PRIMARY  PRIMARY  4  const  1  UNION RESULT  <union1,2>  ALL  EXPLAIN SELECT * FROM employees WHERE employees.EMP_NO IN (100001 ,101100)

in的執行計劃如下

SIMPLE  employees  range  PRIMARY  PRIMARY  4  2  Using whereEXPLAIN SELECT * FROM employees WHERE employees.EMP_NO=100001 OR emp_no=101100

or的執行計劃如下

SIMPLE  employees  range  PRIMARY  PRIMARY  4  2  Using where

感覺結果和第二個實驗還是差不多。

下面本文就采用實例來探討在實際的查詢命令下它們之間的效率對比究竟如何。
1：創建表，插入數據、數據量為1千萬【要不效果不明顯】。

drop table if EXISTS BT; create table BT(   ID int(10) NOT NUll,   VName varchar(20) DEFAULT '' NOT NULL,   PRIMARY key( ID ) )ENGINE=INNODB;

該表只有兩個字段 ID為主鍵【索引頁類似】，一個是普通的字段。（偷懶就用簡單的表結構呢）
向BT表中插入1千萬條數據
這里我寫了一個簡單的存儲過程【所以你的mysql版本至少大于5.0，俺的版本為5.1】，代碼如下。
注意：最好

  INSERT INTO BT ( ID,VNAME ) VALUES( i, CONCAT( 'M', i ) );---1

修改為

  INSERT INTO BT ( ID,VNAME ) VALUES( i, CONCAT( 'M', i, 'TT' ) );---2

   修改原因在
   非索引列及VNAME使用了聯合進行完全掃描請使用1 。
   非索引列及VNAME使用了全表掃描請使用2 。

DROP PROCEDURE IF EXISTS test_proc; CREATE PROCEDURE test_proc() BEGIN declare i int default 0; set autocommit = 0; while i<10000000 do INSERT INTO BT ( ID,VNAME ) VALUES( i, CONCAT( 'M', i ) ); set i = i+1; if i%2000 = 0 then commit; end if; end while; END;

就不寫注釋呢，挺簡單的。
存儲過程是最好設置下innob的相關參數【主要和日志、寫緩存相關這樣能加快插入】，俺沒有設置插入1千萬條數據插了6分鐘。
部分數據如下：1千萬數據類似