MySQL Order By索引優化辦法。本站提示廣大學習愛好者：（MySQL Order By索引優化辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL Order By索引優化辦法正文
雖然 ORDER BY 不是和索引的次序精確婚配，索引照樣可以被用到，只需不消的索引部門和一切的額定的 ORDER BY 字段在 WHERE 子句中都被包含了。
應用索引的MySQL Order By
以下的幾個查詢都邑應用索引來處理 ORDER BY 或 GROUP BY 部門：
SELECT * FROM t1 ORDER BY key_part1,key_part2,... ;
SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2;
SELECT * FROM t1 WHERE key_part1=constant GROUP BY key_part2;
SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC;
SELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2 DESC;
不應用索引的MySQL Order By
在另外一些情形下，MySQL沒法應用索引來知足 ORDER BY，雖然它會應用索引來找到記載來婚配 WHERE 子句。這些情形以下：
* 對分歧的索引鍵做 ORDER BY ：
SELECT * FROM t1 ORDER BY key1, key2;
* 在非持續的索引鍵部門上做 ORDER BY：
SELECT * FROM t1 WHERE key2=constant ORDER BY key_part2;
* 同時應用了 ASC 和 DESC：
SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 ASC;
* 用於搜刮記載的索引鍵和做 ORDER BY 的不是統一個：
SELECT * FROM t1 WHERE key2=constant ORDER BY key1;
* 有許多表一路做銜接，並且讀取的記載中在 ORDER BY 中的字段都不滿是來自第一個異常數的表中（也就是說，在 EXPLAIN 剖析的成果中的第一個表的銜接類型不是 const）。
* 應用了分歧的 ORDER BY 和 GROUP BY 表達式。
* 表索引中的記載不是順次存儲。例如，HASH 和 HEAP 表就是如許。
經由過程履行 EXPLAIN SELECT ... ORDER BY，就曉得MySQL能否在查詢中應用了索引。假如 Extra 字段的值是 Using filesort，則解釋MySQL沒法應用索引。概況請看"7.2.1 EXPLAIN Syntax (Get Information About a SELECT)"。當必需對成果停止排序時，MySQL 4.1之前 它應用了以下 filesort 算法：
1. 依據索引鍵讀取記載，或許掃描數據表。那些沒法婚配 WHERE 分句的記載都邑被略過。
2. 在緩沖中每筆記錄都用一個‘對'存儲了2個值（索引鍵及記載指針）。緩沖的年夜小根據體系變量 sort_buffer_size 的值而定。
3. 當緩沖慢了時，就運轉 qsort（疾速排序）並將成果存儲在暫時文件中。將存儲的塊指針保留起來（假如一切的‘對'值都能保留在緩沖中，就無需創立暫時文件了）。
4. 履行下面的操作，直到一切的記載都讀掏出來了。
5. 做一次多重歸並，將多達 MERGEBUFF（7）個區域的塊保留在另外一個暫時文件中。反復這個操作，直到一切在第一個文件的塊都放到第二個文件了。
6. 反復以上操作，直到殘剩的塊數目小於 MERGEBUFF2 (15)。
7. 在最初一次多重歸並時，只要記載的指針（排序索引鍵的最初部門）寫到成果文件中去。
8. 經由過程讀取成果文件中的記載指針來順次讀取記載。想要優化這個操作，MySQL將記載指針讀取放到一個年夜的塊裡，而且應用它來順次讀取記載，將記載放到緩沖中。緩沖的年夜小由體系變量 read_rnd_buffer_size 的值而定。這個步調的代碼在源文件 `sql/records.cc' 中。
這個切近親近算法的一個成績是，數據庫讀取了2次記載：一次是預算 WHERE 分句時，第二次是排序時。雖然第一次都勝利讀取記載了（例如，做了一次全表掃描），第二次是隨機的讀取（索引鍵曾經排好序了，然則記載並沒有）。在MySQL 4.1 及更新版本中，filesort 優化算法用於記載中不只包含索引鍵值和記載的地位，還包含查詢中請求的字段。這麼做防止了須要2次讀取記載。改良的 filesort 算法做法年夜致以下：
1. 跟之前一樣，讀取婚配 WHERE 分句的記載。
2. 絕對於每一個記載，都記載了一個對應的；‘元組'信息信息，包含索引鍵值、記載地位、和查詢中所須要的一切字段。
3. 依據索引鍵對‘元組'信息停止排序。
4. 順次讀取記載，不外是從曾經排序過的‘元組'列表中讀取記載，而非從數據表中再讀取一次。
應用改良後的 filesort 算法比擬本來的，‘元組'比‘對'須要占用更長的空間，它們很少正好合適放在排序緩沖中（緩沖的年夜小是由 sort_buffer_size 的值決議的）。是以，這便可能須要有更多的I/O操作，招致改良的算法更慢。為了不使之變慢，這類優化辦法只用於排序‘元組'中額定的字段的年夜小總和跨越體系變量 max_length_for_sort_data 的情形（這個變量的值設置太高的一個表象就是高磁盤負載低CPU負載）。想要進步 ORDER BY 的速度，起首要看MySQL可否應用索引而非額定的排序進程。假如不克不及應用索引，可以試著遵守以下戰略：
* 增長 sort_buffer_size 的值。
* 增長 read_rnd_buffer_size 的值。
* 修正 tmpdir，讓它指向一個有許多殘剩空間的公用文件體系。
假如應用MySQL 4.1或更新，這個選項許可有多個途徑用輪回的格局。各個途徑之間在 Unix 上用冒號（':'）分離隔來，在 Windows，NetWare和OS/2 上用分號（';'）。可以應用這個特征將負載均勻分攤給幾個目次。留意：這些途徑必需是散布在分歧物理磁盤上的目次，而非在統一個物理磁盤上的分歧目次。
