MySQL 的 or/in/union，谁能命中索引？（8/38）

方案1最慢：负向查询不命中索引，in 最推荐

《数据库内核原理》第 8 篇：or/in/union 与索引优化。

本文缘起自第 7 篇《MySQL 索引技巧：聚集索引、联合索引与最左前缀》的作业题。

假设订单业务表结构为：

order(oid, date, uid, status, money, time, …)

其中：

oid，订单ID，主键

date，下单日期，有普通索引，管理后台经常按照date查询

uid，用户ID，有普通索引，用户查询自己订单

status，订单状态，有普通索引，管理后台经常按照status查询

money/time，订单金额/时间，被查询字段，无索引

…

假设订单有三种状态：0已下单，1已支付，2已完成

业务需求，查询未完成的订单，哪个SQL更快呢？

select * from order where status!=2

select * from order where status=0 or
status=1

select * from order where status IN (0,1)

select * from order where status=0
union all
select * from order where status=1

结论：方案1最慢，方案2，3，4都能命中索引

但是…

union all 肯定是能够命中索引的

select * from order where status=0
union all
select * from order where status=1

说明：

直接告诉MySQL怎么做，MySQL耗费的CPU最少

程序员并不经常这么写SQL(union all)

简单的in能够命中索引

select * from order where status in (0,1)

说明：

让MySQL思考，查询优化耗费的cpu比union all多，但可以忽略不计

程序员最常这么写SQL(in)，这个例子，最建议这么写

对于or，新版的MySQL能够命中索引

select * from order where status=0 or
status=1

说明：

让MySQL思考，查询优化耗费的cpu比in多，别把负担交给MySQL

不建议程序员频繁用or，不是所有的or都命中索引

对于老版本的MySQL，建议查询分析下

对于!=，负向查询肯定不能命中索引

select * from order where status!=2

说明：

全表扫描，效率最低，所有方案中最慢

禁止使用负向查询

其他方案

select * from order where status < 2

这个具体的例子中，确实快，但是：

这个例子只举了3个状态，实际业务不止这3个状态，并且状态的“值”正好满足偏序关系，万一是查其他状态呢，SQL不宜依赖于枚举的值，方案不通用

这个SQL可读性差，可理解性差，可维护性差，强烈不推荐

作业

这样的查询能够命中索引么？

select * from order where uid in (
         select
uid from order where status=0
)

select * from order where status in (0, 1)
order by date desc

select * from order where status=0 or date
<= CURDATE()

注：此为示例，别较真SQL对应业务的合理性。

检验一下

索引命中规则到此收口，下一篇换到主键的考场——第 9 篇：InnoDB 主键，你真的懂吗？五道练习题自测。

知其然，知其所以然。思路比结论更重要。