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

[大肠猴]

表结构：

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

[不剪发的Tony老师]

你用的是哪个版本 MySQL？

[遇星]

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

[AHUA1001]

执行计划，只是参考，不一定准确。 好多时候，执行计划好的，效率未必好。

[蜕变之痛]

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

[大肠猴]

引用 4 楼 蜕变之痛 的回复:

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

都是 Using where; Using index

[大肠猴]

引用 1 楼 董旭阳TonyDong 的回复:

你用的是哪个版本 MySQL？

5.6版本

[蜕变之痛]

注意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 为具体值，不应该在组合索引后。
目前这个索引基本也是费的。