www.cnblogs.com/tangyanbo/p/6378741.html
select * from acct_trans_log WHERE acct_id = 1000000000009000757
order by create_time desc limit 0,10
select * from acct_trans_log WHERE acct_id = 1000000000009003061
order by create_time desc limit 0,10
索引：acct_id，create_time 分別是單列索引，資料庫總數據為500w。通過 acct_id 過濾出來的結果集在 1w 條左右。查詢結果：第一條要5.018s，第二條0.016s為什麼會是這樣的結果呢？第一，acct_id和create_time都有索引，不應該出現5s查詢時間這麼慢啊 仔細觀察會發現，索引只使用了idx_create_time，沒有用到idx_acct_id。這能解釋第一條sql很慢，因為where查詢未用到索引，那麼第二條為什麼這麼快？看起來匪夷所思，其實搞清楚mysql查詢的原理之後，其實很簡單。我們來看這2條sql查詢，都用到了where order by limit。當有limit存在時，查詢的順序就有可能發生變化，這時並不是從資料庫中先通過where過濾再排序再limit。因為如果這樣的話，從500萬數據中通過where過濾就不會是5s了。此時的執行順序是，先根據idx_create_time索引樹，從最右側葉子節點，反序取出n條，然後逐條去跟where條件匹配。若匹配上，則得出一條數據，直至取滿10條為止，為什麼第二條sql要快，因為運氣好，剛好時間倒序的前幾條就全部滿足了。搞清楚原理之後，我們了解了為什麼第一條慢，第二條快的原因，但是問題又來了為什麼mysql不用idx_acct_id索引，這是一個問題，因為這樣的話，我們的建立的索引基本失效了，在此類sql下查詢效率將會是相當低。因為通過acct_id過濾出來的結果集比較大，有上萬條，mysql認為按時間排序如果不用索引，將會是filesort,這樣會很慢，而又不能2個索引都用上，所以選擇了idx_create_time。這裡為什麼不能2個索引都用上，可能很多人也不知道為什麼，其實道理很簡單，每個索引在資料庫中都是一個索引樹，其數據節點存儲了指向實際數據的指針，如果用一個索引來查詢，其原理就是從索引樹上去檢索，並獲得這些指針，然後去取出數據。試想，如果你通過一個索引，得到過濾後的指針，這時，你的另一個條件索引如果再過濾一遍，將得到2組指針的集合，如果這時候取交集，未必就很快，因為如果每個集合都很大的話，取交集的時候，等於掃描2個集合，效率會很低，所以沒法用2個索引。當然有時候mysql會考慮臨時建立一個聯合索引，將2個索引聯合起來用，但是並不是每種情況都能奏效，同樣的道理，用一個索引檢索出結果集之後，排序時，也無法用上另一個索引了。實際上用索引idx_acct_id大多數情況還是要比用索引idx_create_time要快，我們舉個例子：
select * from acct_trans_log force index(idx_acct_id)
WHERE acct_id = 1000000000009000757
order by create_time desc limit 0,10
可以看出改情況用idx_acct_id索引是比較快的，那麼是不是這樣就可以了呢，排序未用上索引，始終是有隱患的。
select * from acct_trans_log force index(idx_acct_id)
WHERE acct_id = 3095
order by create_time desc limit 0,10
該sql通過acct_id過濾出來的結果集有100萬條，因此排序將會耗時較高，所幸這裡只是取出前10條最大的然後排序查詢概況，我們發現時間基本消耗在排序上，其實這是內存排序，對內存消耗是很高的。那麼我們有沒有其它解決方案呢，這種sql是我們最常見的，如果處理不好，在大數據量的情況下，耗時以及對資料庫資源的消耗都很高，這是我們所不能接受的，我們的唯一解決方案就是讓where條件和排序欄位都用上索引
alter table acct_trans_log add index idx_acct_id_create_time(acct_id,create_time)
select * from acct_trans_log WHERE acct_id = 3095
order by create_time desc limit 0,10
聯合索引讓where條件欄位和排序欄位都用上了索引，問題解決了！但是為什麼能解決這個問題呢，這時大家可能就會記住一個死理，就是聯合索引可以解決where過濾和排序的問題，也不去了解其原理，這樣是不對的，因為當情況發生變化，就懵逼了，
select * from acct_trans_log force index(idx_acct_id_create_time)
WHERE acct_id in(3095,1000000000009000757)
order by create_time desc limit 0,10
索引還是用idx_acct_id_create_time，時間居然慢下來了。 看執行計劃，排序用到了filesort，也就是說，排序未用到索引。那麼我們還是來看看，索引排序的原理，我們先來看一個sql:
select * from acct_trans_log
ORDER BY create_time limit 0,100
這裡執行的步驟是，先從索引樹中，按時間升序取出前100條，因為索引是排好序的，直接左序遍歷即可了，因此，這裡mysql並沒有做排序動作，如果想降序，則右序遍歷索引樹，取出100條即可，查詢固然快，那麼聯合索引的時候，是怎樣的呢？
select * from acct_trans_log
WHERE acct_id = 3095
order by create_time desc limit 0,10
使用組合索引：idx_acct_id_create_time。這個時候，因為acct_id是聯合索引的前綴，因此可以很快實行檢索，如果sql是
select * from acct_trans_log WHERE acct_id = 3095
select * from acct_trans_log
WHERE acct_id = 3095
order by create_time
如果我們把條件換成order by create_time desc limit 0,10呢？這時候，應該從idx_acct_id_create_time樹右邊葉子節點倒序遍歷，取出前10條即可因為數據的前綴都是3095，後綴是時間升序。那麼我們倒序遍歷出的數據，剛好滿足 order by create_time desc。因此也無需排序。
select * from acct_trans_log force index(idx_acct_id_create_time)
WHERE acct_id in(3095,1000000000009000757)
order by create_time desc limit 0,10
已知：id1<id2<id3... time1<time2<time3....索引出來的默認排序是這樣的，id是有序的，時間是無序的，因為有2個id，優先按id排序，時間就是亂的了，這樣排序將會用filesort，這就是慢的原因，也是排序沒有用到索引的原因。type：顯示使用了何種類型，從最好到最差的連接類型為const,eq_ref,ref,range,index,allpossible_keys：顯示可能應用在這張表中的索引。如果為空，沒有可能的索引key：實際使用的索引，如果為null，則沒有使用索引。key_len：使用的索引的長度。在不損失精確性的情況下，長度越短越好ref：顯示索引的哪一列被使用了，如果可能的話，是一個常數rows：mysql認為必須檢查的用來返回請求數據的行數