博客讲述了作者遇到的一个MySQL查询优化器选择全表扫描而非预期索引的问题。当SQL包含`order by id asc limit 1`时，优化器为了避免排序而选择全表扫描，但实际上使用索引更快。该问题自2014年起存在，至今未在某些版本中修复。解决方案包括使用`force index`或`order by (id+0)`来指导优化器选择正确索引。
这周收到一个 sentry 报警，如下 SQL 查询超时了。
select * from order_info where uid = 5837661 order by id asc limit 1
执行show create table order_info 发现这个表其实是有加索引的
CREATE TABLE `order_info` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`uid` int(11) unsigned,
`order_status` tinyint(3) DEFAULT NULL,
... 省略其它字段和索引
PRIMARY KEY (`id`),
KEY `idx_uid_stat` (`uid`,`order_status`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8
理论上执行上述 SQL 会命中 idx_uid_stat 这个索引，但实际执行 explain 查看
explain select * from order_info where uid = 5837661 order by id asc limit 1
可以看到它的 possible_keys（此 SQL 可能涉及到的索引） 是 idx_uid_stat，但实际上（key）用的却是全表扫描
<
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
