发现一个很奇怪的问题。mysql中explain的type index效率比range高

Question

表结构：sql：
SELECT vod_id FROM `ia_comment` where vod_id>0 and account_id=88;
SELECT vod_id FROM `ia_comment` where account_id=88;
结果：
[SQL]SELECT vod_id FROM `ia_comment` where vod_id>0 and account_id=88;
受影响的行: 0
时间: 0.323s[SQL]
SELECT vod_id FROM `ia_comment` where account_id=88;
受影响的行: 0
时间: 0.152s
为什么第二条sql扫描的rows多效率反而更高
两条sql得到的数据是一样的
vod_id 全部大于0

Answer 1

你用的是哪个版本 MySQL？

Answer 2

注意key_len，第一条SQL是4，说明只用到了联合索引的第一个列vod_id，所以vod_id这个索引只用于vod_id>0的筛选，从索引读取数据之后，还要进行account_id=88的判断，慢就是慢在多出了另外判断account_id=88；
而第二条key_len是8，也就是说，where条件直接在索引上判断。
所以第二条会快一点。

Answer 3

为什么 possible_key  是空，key是非空，没见过。extra内容不全，无法进一步判断。

Answer 4

都是 Using where; Using index

Answer 5

注意key_len：
      第一条SQL是4，说明只用到了联合索引的第一个列vod_id，所以vod_id这个索引只用于vod_id>0的筛选，从索引读取数据之后，还要进行account_id=88的判断。
      第二条SQL是8，说明用的是组合索引。rows：
      当只用索引void_id时，vod_id>0 时，索引可能扫描25w+，当用组合做引时，可能扫描51W+，这个数据有时会是过期的不正确（有时需要table analysis下），用1列索引，2列索引时，有自己的策略，并不是说有50w 索引扫描就是50w，有可能是25W。时间：
      第一条、根据索引扫描后，每条都需要再次判断是否=88。
      第二条、根据索引可以直接定位到目标行。这个把重点搞偏了，vod_id全部>0, 不应这样写where条件。account_id 为具体值，不应该在组合索引后。
目前这个索引基本也是费的。