此文是根據原作者所著加上自己的理解總結出來的，如果有什麼問題歡迎各位提出一起交流探討。先貼出原文如下：

某前臺sql語句，簡化後如下
SELECT products_name,products_viewed FROM `products_description` 
ORDER BY products_viewed DESC,products_name LIMIT 0,20;

該語句經常大批量出現在慢日誌中！

初步看改語句，非常簡單，根據products_viewed(產品被檢視次數)倒序排序，再根據products_name（產品名字）排序！在products_viewed和products_name上分別建立有索引！
但是感覺products_name排序怪怪的！
explain後發現
+----+-------------+----------------------+------+---------------+------+---------+------+-------+----------------+
| id | select_type | table                | type | possible_keys | key  | key_len | ref  | rows  | Extra          | 
+----+-------------+----------------------+------+---------------+------+---------+------+-------+----------------+
|  1 | SIMPLE      | products_description | ALL  | NULL          | NULL | NULL    | NULL | 764370 | Using filesort | 
+----+-------------+----------------------+------+---------------+------+---------+------+-------+----------------+

改語句做竟然全表掃描！

mysql的order by語句，如果在where條件中沒有合適的索引選擇時，將會選擇order by col中的索引作為條件，但是如果是多個order by組合，將會導致放棄使用索引！
和開發以及需求溝通，發現通過名字排序是可以不需要的！
我們去掉order by後面的 products_name!
再次explain後發現已經能夠使用索引:
explain SELECT products_name,products_viewed FROM `products_description` 
 ORDER BY products_viewed LIMIT 0,20; 
+----+-------------+----------------------+-------+---------------+-----------------+---------+------+------+-------+ 
| id | select_type | table                | type  | possible_keys | key            | key_len | ref  | rows | Extra | 
+----+-------------+----------------------+-------+---------------+-----------------+---------+------+------+-------+ 
|  1 | SIMPLE      | products_description | index | NULL          | products_viewed | 5      | NULL |  20 |      | 
+----+-------------+----------------------+-------+---------------+-----------------+---------+------+------+-------+

再次對比兩次profiling(過程省略)，發現第一次損壞大量io和cpu時間Sorting result上！因為該語句為前臺語句，有大量查詢，優化後，頁面開啟速度明顯提升！

注意：
1. order by m,n  不要輕易寫這種語句，一般的order by前面的m才是order by的重點，後面的n為配角，如果沒有必要，儘量去掉
2. 參考我的另一篇 http://www.linuxidc.com/Linux/2014-03/98549.htm

之後我發現order by 後面的欄位如果是前面select語句沒有查詢的話，會出現某些無法預料的結果。現將我兩次查詢的結果貼在下面，暫時還不知道出現這種情況的原因。

第一次查詢，select了order by 後面的欄位，結果截圖如下：

第二次查詢，order by 後面的欄位並沒有跟在select後面，結果截圖如下：

兩次查詢的結果完全不同，使用DISTINCT語句並沒有出現預期出現的結果：即取出唯一的第一列資料A以及跟此列相關聯的列資料B。而不是將A、B兩列資料都是DISTINCT。查閱相關論壇終於發現可以用select A，B，count(*) from tablename group by A having B>=1 來實現需求。但是問題又來了，這樣查詢的速度比較慢，因為涉及分類計數等，我用下面的SQL語句查詢兩張20w級別的表，執行一次所需的時間為6s左右。所查詢的相關列都已建立索引。 

後來想到資料庫應該只執行查詢，存取資料的功能，其餘交給後臺來執行，於是建立了一張新表，偽外來鍵的形式解決了問題。SQL如下：

CREATE TABLE relation AS  (select `litigationinfo`.`org-name` AS A, max(`litigationinfo`.`release-time`) AS B,count(DISTINCT `litigationinfo`.`org-name`) AS C from `litigationinfo`,`enterpriseinfo` where  `litigationinfo`.`org-name` = `enterpriseinfo`.`org-name` group by A having C=1 order by B desc);

ALTER  TABLE  `relation`  ADD  PRIMARY  KEY (  `A`  ) ;
ALTER  TABLE  `relation`  ADD  INDEX relation_index_2 (  `B`  )