资源描述：
《mysql实战or、in与unionall的查询效率》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。
1、mysql实战or、in与unionall的查询效率OR、in和unionall查询效率到底哪个快。网上很多的声音都是说unionall快于or、in，因为or、in会导致全表扫描，他们给出了很多的实例。但真的unionall真的快于or、in?本文就是采用实际的实例来探讨到底是它们之间的效率。1：创建表，插入数据、数据量为1千万【要不效果不明显】。1.droptableifEXISTSBT;2.createtableBT(3.IDint(10)NOTNU11,4.VNamevarchar(20)DEFAULT11NOTNULL,5・PRIMARYkey(ID)6.)ENGINE=I
2、NNODB；该表只有两个字段ID为主键【索引页类似】,一个是普通的字段。(偷懒就用简单的表结构呢)向BT表中插入1千万条数据这里我写了一个简单的存储过程【所以你的mysql版本至少大于5.0,俺的版本为5.1】，代码如下。注意：最好INSERTINTOBT(ID,VNAME)VALUES(i,CONCAT(・WT,i));―1修改为INSERTINTOBT(ID,VNAME)VALUES(i,CONCAT(仙，i,•TT*));—2修改原因在非索引列及VNAME使用了联合进行完全扫描请使用1。非索引列及VNAME使用了全表扫描请使用2o1.DROPPROCEDUREIFEXISTSt
3、est_proc;2.CREATEPROCEDUREtest_proc()3.BEGIN4.declareiintdefault0;5.setautocommit二0;6.whilei<10000000do7.INSERTINTOBT(ID,VNAME)VALUES(i,CONCAT(i));8.seti=i+1;1.ifi%2000=0then2.commit;11>endif;12.endwhile;13.END;就不写注释呢，挺简单的。存储过程是最好设置下innob的相关参数【主要和口志、写缓存相关这样能加快插入】，俺没有设直插入1千万条数据插了6分钟。部分数据如下：1「万数据
4、类似nysql>select*fromBTLIMIT6；lIDIUNanei：0：M0!!1!Ml!：2：M2!!3!M3!14!M4!15IM5I6rowsinset<0.00sec>2：实战2.1:分别在索引列上使用or、in、unionall我们创建的表只有主键索引，所以只能用ID做查询呢。我们查ID为98,85220,9888589的三个数据各个耗时如下：nysql>select*frombtwherebt.ID一、-=98orbt.ID=85220orbt.ID=9888589X••一■”■■一•—■9+-4-:ID!UNameI1+—*一+-+119&!M981l!852
5、20!M85220l1!9888589M988858911++-+3rowsinset<0.00;sec>nysql>select*fronbtwherebt.IDin<98,85220,9888589>；+十JID:UNane■■++-+1198；M98■i:85220!M85220■i!9888589!M9888589ii++-+3rowsinset<0.00;sec)mysql>select*frombtwherebt.ID=98_>UNIONALL->select*frombtwherebt.ID=85220->UNIONALL_>select*frombtwherebt.
6、ID=9888589；+.-+；ID■UNamei■+十；98:M98■i!85220!M85220i■!9888589!M9888589i■十+-+l3rowsinset<0.00isec>时间都为0.00,怎么会这样呢，呵呵所有査询都是在毫秒级别。我使用其他的工具—EMSSQLManagerformysql查询显示时间为93ms,94ms,93ms,时间相差了多少儿乎可以忽略。然后我们在看看各自的执行计划nysql>explain->select*fronbtwherebt.ID=98orbt.ID=85220orbt.ID=9888589->；Ikey_lenIrefIrows
7、丨Extr«IidIselect_typeItableItypeIpossible_keysIkey1!SIMPLE!range!PRIMARY!PRIMARY!4!NULL!3!Usingwhcre；Usingindex!1rowinset<0.00sec>一〉scloct*fronbtwherebt.IDin<98,85220,9888589>；id!select_type!table!type!possible_J
