今天寫了一個統(tǒng)計sql，在一個近億條數(shù)據(jù)的表上執(zhí)行，200s都查不出結(jié)果。SQL如下：

select customer,count(1) c  
from upv_1  
where created between "2015-07-06" and "2015-07-07"  
group by customer   
having c > 20  
order by c desc  

執(zhí)行explain,發(fā)現(xiàn)這個sql掃描了8000W條記錄到磁盤上。然后再進(jìn)行篩選。type=index說明整個索引樹都被掃描了，效果顯然不理想。

image

拿著這個SQL去請教項目組的數(shù)據(jù)庫大牛，僅僅加了一個force index，花了1s多就出結(jié)果了。修改后的SQL如下：

select customer,count(1) c  
from upv_1  force index(idx_created)  
where created between "2015-07-06" and "2015-07-07"  
group by customer   
having c > 15  
order by c desc  

同樣執(zhí)行以下explain命令，這個SQL僅僅掃描了磁盤的110W行記錄。也就是上一個SQL的80分之一。大家都知道，掃描磁盤是很耗時的IO操作，比內(nèi)存操作慢幾個數(shù)量級。type=range,說明索引樹僅僅被部分掃描，要優(yōu)于前面那個SQL.

image

除了磁盤掃描的行數(shù)的不一樣，還有采用的索引的不同，上面的sql用的是聯(lián)合索引，而下面的是單純的created字段的索引。由于用的是created的索引，驅(qū)動條件就是created的區(qū)間，需要掃描的數(shù)據(jù)就立刻變小了，因為時間區(qū)間小。后面的SQL的key_len要遠(yuǎn)遠(yuǎn)小于前面的SQL，也就意味著要掃描的磁盤上的索引數(shù)據(jù)量要遠(yuǎn)遠(yuǎn)小于前面的SQL。

第一個sql使用的是錯誤的索引，帶來低效的查詢。然后每條SQL只可能使用一個索引。通過上面的分析就可以發(fā)現(xiàn)，force index()指令可以指定本次查詢使用哪個索引！一條sql只會用到一個索引，mysql優(yōu)化器會計算出一個合適的索引，但是這個索引不一定是最好的。force index()指令可以避免MySql優(yōu)化器用到了一個低效的索引。

總結(jié)：mysql可能并不總會選擇合適且效率高的索引去查詢，這時適當(dāng)?shù)膄orce index(indexname) 強(qiáng)制告訴mysql使用什么索引尤為重要。