mysql中,like比=更快

findever 发布于 2013/05/05 12:53
阅读 888
收藏 3

70万数据,符合where条件的,都是30多万,callstate已索引

1.select sum(usercost) from core_cdr where callstate like 'A%';
2.select sum(usercost) from core_cdr where callstate = 'ANSWER';
查询结果:

语句1:耗时0.51s

语句2:耗时0.81s

另explain结果中,语句1 type为ALL,语句2 type为ref

求解,为何语句1反而比语句2更高效,语句1的查询类型为ALL,会不会有额外的开销,即“不良后果”

加载中
0
O油菜
O油菜

LIKE 'A%'匹配一个A就不用继续解析了,定然更快。

='ANSWER'每条记录至少要匹配2个字才能返回结果,最多要匹配6个。

findever
findever
回复 @屁屁果 : %A%就用不了索引了,那就是个悲剧
O油菜
O油菜
回复 @屁屁果 : …………我目前在写C++,这个机子上没有MySQL。倒是有Mongo……
光石头
光石头
我这里不方便测试,你造点数据测试下。还有,你去掉索引再测试下like和=的效率
O油菜
O油菜
回复 @屁屁果 : %A%就慢了呗,解析器会挨个匹配查找A。但是如果callstate列中长过6个字的项很少,%A%还会比='ANSWER'快的。否则二者效率会是差不多。
光石头
光石头
你写成 like '%A%' 再看下效率,我一直的原则都是能用=坚决不用like
下一页
0
huan
huan

看看查询规划,第二条走了索引么? 

另外,缓存,是否冷启,都会影响到速度。

findever
findever
两条肯定都走索引了,不然怎么可能是1s以下
0
UlricQin
UlricQin
callstate肯定没加索引
findever
findever
加了,前面有说明
0
Tuesday
Tuesday
楼主, 我能告诉你是sum的原因不?
findever
findever
。。这能有啥原因,就是要累加的结果呗
0
UlricQin
UlricQin
符合条件的30多万……我了个去,没注意这个前提,加了索引还不如没索引自然是正常的
findever
findever
错了,是2.x秒
findever
findever
不加索引1.x秒,不是一个级别的
0
UlricQin
UlricQin
callstate是varchar?改成char试试呢
0
魔力猫
魔力猫
需要处理的记录太多了,所以全表比索引快。当然,如果你 usercost也在索引中就快了。
findever
findever
回复 @魔力猫 : 是的,走的是单索引,所以我把usercost的索引去掉了
魔力猫
魔力猫
回复 @findever : 那么usercost的索引就不起作用,所以不如全表快。
findever
findever
回复 @魔力猫 : 独立的索引
魔力猫
魔力猫
回复 @findever : 复合索引callstate,usercost有?
findever
findever
之前也索引了usercost,但是事实是,加了更慢= =
0
mark35
mark35
两条语句结果集都不能确认是相同的,做比较没啥意思
findever
findever
一致的,不一致我就不来比较了
0
苦寒竹
苦寒竹
1楼应该是正解。如果是%A%就非常慢了。查询就是匹配问题。A%只要比较第一个字母就可以了,比完全匹配(=ANSWER)要快。
返回顶部
顶部