1. mysql在資料量較大的時候、使用order by查詢結果集時速度很慢的原因可能有以下幾種：

1） 排序欄位不在同一張表中

2） 排序欄位沒有建索引

3）排序欄位加DESC後索引沒有起作用（如何讓索引起作用才是關鍵、且聽下文分解）

4）排序欄位中加函式導致索引不起作用（這種一定要避免、本文不對這種情況展開說明）

5）排序欄位中含有TEXT或CLOB欄位（改成VARCHAR欄位）

2. 用例項說明排序欄位中增加DESC後索引不起作用、查詢速度很慢

1）例如以下SQL、執行起來需要5秒左右、太慢不可接受：

SELECT T.WK_ID, T.WK_NAME, C.CR_CODE, T.AT_BEGIN_TIME, T.WK_BOOK
  FROM BO_COPYRIGHT C
 INNER JOIN ES_WORKS_INFO T
    ON T.CR_ID = C.CR_ID
   AND C.WK_ID_VALID = T.WK_ID
   AND T. DELETEFLAG = 0
 ORDER BY T.AT_BEGIN_TIME DESC, T.WK_BOOK

 LIMIT 1, 100

其中 ES_WORKS_INFO 的AT_BEGIN_TIME 和WK_BOOK建有聯合索引

2）效能慢的原因分析

實際上檢視執行計劃後發現索引沒有起作用、Using where; Using filesort。

執行計劃如下：

SIMPLE  t  ALL        PRIMARY,idx_CR_ID                                                         480006   Using where; Using filesort

SIMPLE  c  eq_ref     PRIMARY,idx_WK_VALID   PRIMARY  4   nrps.t.CR_ID   1             Using where

Using filesort。是的，看到它，說明我們的查詢需要優化了：檔案排序是通過相應的排序演算法，將取得的資料在記憶體中進行排序。聯合索引沒有起作用。將ORDER BY中的DESC去掉後執行完只要0.3秒。那為什麼加了DESC後會變慢呢？業務要求必須加上DESC怎麼辦呢？

先來分析一下SQL執行慢的底層原因是什麼？

我先查了一下複合索引的欄位順序和order by中的欄位順序是一致的、那為什麼還是這麼慢呢？為什麼還是Using filesort？為什麼索引不起作用呢？

MySql 索引建立手冊裡如是說：
索引列的定義可以跟隨 ASC 或者 DESC。這些關鍵字允許為未來擴充套件用於指定升序或降序索引值儲存。這個語法會被解析但卻被忽略。索引列總是以升序排列。——也就是說你寫了不會報錯，但寫了白寫。

這樣看來，我們的複合索引沒起排序作用，原因就在於我們的索引中各欄位 asc 儲存， order by 裡 desc 和 asc(預設是 asc) 混用。為了驗證這個說法，我們把該 order by 各個欄位換為一致的 desc試試:

SELECT T.WK_ID, T.WK_NAME, C.CR_CODE, T.AT_BEGIN_TIME, T.WK_BOOK
  FROM BO_COPYRIGHT C
 INNER JOIN ES_WORKS_INFO T
    ON T.CR_ID = C.CR_ID
   AND C.WK_ID_VALID = T.WK_ID
   AND T. DELETEFLAG = 0
 ORDER BY T.AT_BEGIN_TIME DESC, T.WK_BOOK DESC

 LIMIT 1, 100

果然效能一下子提高了、執行時間0.3秒結束。

但是有個遺憾如果業務上必須要求一個欄位DESC另一個欄位ASC的話、這個SQL語句怎麼優化能？有哪個大牛知道的話、請賜教！[email protected]

3.關於ORDER BY慢的情況下可以從以下幾點進行優化：

1）ORDER BY的欄位改到一種表、不要誇表（設計表結構時需注意這一點）

2）OEDER BY欄位建索引、多個欄位時建聯合索引（聯合索引的欄位順序要與ORSER BY中的欄位順序一致）

3）ORDER BY中欄位中聯合索引的所有欄位DESC或ASC要統一，否則索引不起作用

4）不要對TEXT欄位或者CLOB欄位進行排序

4.以下是另一個技術大牛【陳小峰_iefreer】整理的跟ORDER BY有關的知識點

原文地址：https://blog.csdn.net/iefreer/article/details/12622097