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

知识点掌握了，还需要不断练习才能熟练运用。下面golang学习网给大家带来一个数据库开发实战，手把手教大家学习《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 这个具体的例子中，确实快，但是：
这个例子只举了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

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

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。