问题:

这个bug来源于官方的一个bug报告,感谢@印风_小希 . 现象很容易描述,直接上例子. 5.1以后的版本都有此问题.

CREATE TABLE `tb` ( `a` int(11) DEFAULT NULL, `b` int(11) DEFAULT NULL, KEY `a` (`a`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into tb values (1,2),(2,5),(3,8),(4,6);

select * from tb force index (a) where a >=0.5; +------+------+ | a | b | +------+------+ | 2 | 5 | | 3 | 8 | | 4 | 6 | +------+------+ 4 rows in set (0.00 sec)

(1,2)这个记录没有返回.

说明一下,select语句中用force index是以防全表扫描. (不走索引a就正常了).

原因分析:

MySQL使用索引时,调用innoDB的index_read接口, 需要传入三个信息: 查找的值\索引\查找方向, 由于查询条件是>=, 因此查询方向可选的是HA_READ_AFTER_KEY和 HA_READ_KEY_OR_NEXT,分别对应>和>=.

但是传入之前还要作查询优化.

在这个例子中的流程:

1) MySQL决定使用索引a后, 根据输入的值(0.5),取索引[1, MAX). 之所以取1,是因为a是一个int类型.;

2) 判断 0.5和1的大小, 0.5<1, 因此设置 tree->min_flag= NEAR_MIN; 表示实际要查找的值,小于传入索引范围的最小值.因此决定了使用HA_READ_AFTER_KEY, 也就是>0.5, 这没问题.

3) 不幸的是,由于字段a是整型,真正传入的是1, 逻辑变成>1.

所以查找时a=1这个记录被忽略了.

简单修改:

5.0版本没这个问题,那时候没有HA_READ_AFTER_KEY 和 HA_READ_KEY_OR_NEXT这些东西.

这两个值的差别只是在innoDB内部查找的时候要不要判断相等的那个值,简单的修改可以都处理为HA_READ_KEY_OR_NEXT. 不用担心MySQL把>变成>=以后的后果,MySQL层会再作过滤.

当然上面是偷懒的做法, 比较正规的做法应该是在1)判断大小的时候, 把0.5取整为1,这样判断到1=1, 就会标记为HA_READ_KEY_OR_NEXT.