orderby滿足兩種情況,會使用Index方式排序 1. orderby語句使用索引最左前列 2. 使用where子句與orderby子句條件列組合滿足索引最左前列 如果不在索引列,filesort有兩種算法:雙路排序和單路排序 **雙路排序**: mysql之前是使用雙路排序,要掃兩次磁盤,最終得到數據.讀取行指針和orderby列,對他們進行排序,然后掃描已經排序好的列表,按照列表中的值重新從列表中讀取對應的數據輸出.從磁盤取排序字段,在buffer進行排序,再從磁盤取其他字段. **單路排序**: 從磁盤讀取查詢所需要列,按照orderby列在buffer對他們進行排序,然后掃描排序后的列表進行輸出,它的效率更快一些,避免第二次讀取數據.變為順序IO,但是會使用更多空間,因為把每一行都保存到內存中了. **單路排序問題**: 在`sort_buffer`中,方法B比方法A要占用更多空間,因為方法B是把所有字段都取出,所以有可能取出的數據的總大小超出了`sort_buffer`的容量,導致每次只能取出`sort_buffer`容量大小的數據,進行排序(創建tmp文件,多路合并),排完再取`sort_buffer`容量帶下,再排...,從而導致多次IO. 本來想一次IO,反而導致了多次IO操作,得不償失. **單路優化策略** * 增大`sort_buffer_size`參數的設置 * 增大`max_length_for_sort_data`參數的設置 **提高orderby排序** 1. orderby中`select *`是不好的 2. 當query字段大小總和小于`max_length_for_sort_data`而且排序字段不是TEXT|BLOB類型時,會用改進后的算法-單路排序,否則用老算法,多路排序 3. 兩種算法都有可能超出sort_buffer的容量,超出之后,會創建tmp文件進行合并排序,導致多次IO.單路風險更大一點 4. 嘗試提高`sort_buffer_size`,這個參數是針對每個線程的 5. 嘗試提高`max_length_for_sort_data` **為排序使用索引** `key a_b_c (a,b,c)` orderby能使用索引最左前綴 ~~~ order by a desc, b desc, c desc ~~~ 如果where使用索引的最左前綴定義為常量,則orderby能使用索引 ~~~ where a = const order by b, c where a = const and b = const order by c where a = const order by b, c where a = const and b > const order by b, c ~~~ 不能使用索引 ~~~ order by a asc, b desc, c desc //排序不一致 where g = const order by b, c //丟失a索引 where a = const order by c //丟失b索引 where a = const order by a, d //d不是索引一部分 where a in (...) order by b, c //對于排序來說,多個相等條件也是范圍查詢 ~~~