這時我把userid加入索引：
create index userid on imgs (userid);然後再檢查：
MySQL> desc select * from imgs where userid="7mini" order by clicks desc limit 10;嗯，這時可以看到MySQL使用了userid這個索引搜索了，用userid索引一次搜索後，結果集有8條。然後雖然使用了filesort一條一條排序，但是因為結果集只有區區8條，效率問題得以緩解。
但是，如果我用別的userid查詢，結果又會有所不同：
MySQL> desc select * from imgs where userid="admin" order by clicks desc limit 10;這個結果和userid="7mini"的結果基本相同，但是MySQL用userid索引一次搜索後結果集的大小達到2944條，這2944條記錄都會加入內存進行filesort，效率比起7mini那次來說就差很多了。這時可以有兩種辦法可以解決，第一種辦法是再加一個索引和判斷條件，因為我只需要根據點擊量取最大的10條數據，所以有很多數據我根本不需要加進來排序，比如點擊量小於10的，這些數據可能占了很大部分。
我對clicks加一個索引，然後加入一個where條件再查詢：
create index clicks on imgs(clicks);
MySQL> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| 1 | simple | imgs | ref | userid,clicks | userid | 51 | const | 2944 | using where; using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)
這時可以看到possible_keys變成了userid,clicks，possible_keys是可以匹配的所有索引，mysql會從possible_keys中自己判斷並取用其中一個索引來執行語句，值得注意的是，mysql取用的這個索引未必是最優化的。這次查詢mysql還是使用userid這個索引來查詢的，並沒有按照我的意願，所以結果還是沒有什麼變化。改一下sql加上use index強制MySQL使用clicks索引：
MySQL> desc select * from imgs use index (clicks) where userid='admin' and clicks>10 order by clicks desc limit 10
