MySQL的or/in/union与索引优化

　　假设订单业务表结构为：

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，建议查询分析下

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

select * from order where status!=2

　　说明：

• 全表扫描，效率最低，全部方案中最慢

• 禁止使用负向查询

　　5、其余方案

select * from order where status < 2

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

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

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

　　6、做业

　　这样的查询可以命中索引么？

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();