本文緣起自《一分鐘了解索引技巧》的作業(yè)題。

假設(shè)訂單業(yè)務(wù)表結(jié)構(gòu)為：

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

其中：

• oid，訂單ID，主鍵
• date，下單日期，有普通索引，管理后臺經(jīng)常按照date查詢
• uid，用戶ID，有普通索引，用戶查詢自己訂單
• status，訂單狀態(tài)，有普通索引，管理后臺經(jīng)常按照status查詢
• money/time，訂單金額/時間，被查詢字段，無索引
• …

假設(shè)訂單有三種狀態(tài)：0已下單，1已支付，2已完成

業(yè)務(wù)需求，查詢未完成的訂單，哪個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 

結(jié)論：方案1最慢，方案2，3，4都能***索引

但是...

一：union all 肯定是能夠***索引的

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

說明：

• 直接告訴MySQL怎么做，MySQL耗費的CPU最少
• 程序員并不經(jīng)常這么寫SQL(union all)

二：簡單的in能夠***索引

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

說明：

• 讓MySQL思考，查詢優(yōu)化耗費的cpu比union all多，但可以忽略不計
• 程序員最常這么寫SQL(in)，這個例子，最建議這么寫

三：對于or，新版的MySQL能夠***索引

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

說明：

• 讓MySQL思考，查詢優(yōu)化耗費的cpu比in多，別把負(fù)擔(dān)交給MySQL
• 不建議程序員頻繁用or，不是所有的or都***索引
• 對于老版本的MySQL，建議查詢分析下

四、對于!=，負(fù)向查詢肯定不能***索引

select * from order where status!=2 

說明：

• 全表掃描，效率***，所有方案中最慢
• 禁止使用負(fù)向查詢

五、其他方案

select * from order where status < 2 

這個具體的例子中，確實快，但是：

• 這個例子只舉了3個狀態(tài)，實際業(yè)務(wù)不止這3個狀態(tài)，并且狀態(tài)的“值”正好滿足偏序關(guān)系，萬一是查其他狀態(tài)呢，SQL不宜依賴于枚舉的值，方案不通用
• 這個SQL可讀性差，可理解性差，可維護性差，強烈不推薦

六、作業(yè)

這樣的查詢能夠***索引么?

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對應(yīng)業(yè)務(wù)的合理性。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文