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

四、对于!=，负向查询肯定不能***索引

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对应业务的合理性。

【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

云服务器