共計 3053 個字符，預計需要花費 8 分鐘才能閱讀完成。
今天就跟大家聊聊有關 MySQL 數據庫 ORDER BY 優化是怎樣的呢，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
在使用 order by 時，經常出現 Using filesort，所以對于此類 sql 語句我們需要去盡力優化，使其盡量使用 Using index。
那么，我們對于這類型的語句我們怎么去做優化呢? 因為這一塊還是比較容易混淆的，所以我弄了個實驗，相信大家跟我一起做下實驗就都能理解了~
1. 環境準備
drop table if exists test; create table test( id int primary key auto_increment, c1 varchar(10), c2 varchar(10), c3 varchar(10), c4 varchar(10), c5 varchar(10) ) ENGINE=INNODB default CHARSET=utf8; insert into test(c1,c2,c3,c4,c5) values(a1 , a2 , a3 , a4 , a5 insert into test(c1,c2,c3,c4,c5) values(b1 , b2 , b3 , b4 , b5 insert into test(c1,c2,c3,c4,c5) values(c1 , c2 , c3 , c4 , c5 insert into test(c1,c2,c3,c4,c5) values(d1 , d2 , d3 , d4 , d5 insert into test(c1,c2,c3,c4,c5) values(e1 , e2 , e3 , e4 , e52. 創建 btree 索引
create index idx_c1234 on test(c1,c2,c3,c4); show index from test;3. 范圍掃導致全表掃描
explain select * from test where c1 a1 order by c1;分析：
在 c1,c2,c3,c4 上創建了索引，直接在 c1 上使用范圍，導致了索引失效，全表掃描：type=ALL，ref=Null。因為此時 c1 主要用于排序，并不是查詢。
使用 c1 進行排序，出現了 Using filesort。
解決方法：使用覆蓋索引。
4、覆蓋索引 –》優化
explain select c1 from testwhere c1 a1 order by c1;分析：
使用了覆蓋索引，不走全掃，走索引范圍掃描
排序時按照索引的順序，所以不會出現 Using filesort。
這里不懂沒關系，后面我會分享索引的八大法則，保證看得懂 …
5. 沒有按最左列索引排序
explain select c1 from testwhere c1 a1 order by c2;分析：
這里出現了 Using filesort，是因為排序用的 c2，與索引的創建順序 (c1,c2,c3,c4) 不一致。
6. 排序索引列與索引創建的順序相反
explain select c1 from testwhere c1 a1 order by c2,c1;分析：
這里出現了 Using filesort。因為排序索引列 (c2,c1) 與索引創建的順序 (c1,c2) 相反，從而產生了重排，也就出現了 Using filesort。
7. order by 索引列排序不一致
explain select c1 from testwhere c1 a1 order by c1 asc,c2 desc;分析：
雖然排序的字段列與索引順序一樣，且 order by 默認升序，這里 c2 desc 變成了降序，導致與索引的排序方式不同，從而產生 Using filesort。如果是 order by c1 asc,c2 asc 或者 order by c1 desc,c2 desc 就會是 using index 了。
實驗總結
1. MySQL 支持兩種方式的排序 filesort 和 index
Using index 是指 MySQL 掃描索引本身完成排序。index 效率高，filesort 效率低。
2. 為排序使用索引
假設 KEY test(a,b,c)
(1) order by 能使用索引最左前綴
-order by a -order by a,b -order by a,b,c -order by a asc,b asc,c asc -order by a desc,b desc,c desc(2) 如果 where 使用索引最左前綴定位為常量，則 order by 可以使用索引
-where a= const order by b,c -where a= const and b= const order by c -where a= const and b consst order by b,c(3) 不能使用索引進行排序
-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 /* 對于排序來說，多個相等條件也是范圍查詢 */3. filesort 有兩種排序算法：雙路排序和單路排序
雙路排序：在 MySQL4.1 之前使用雙路排序，就是兩次磁盤掃描，得到最終數據。讀取行指針和 order by 列，對他們進行排序，然后掃描已經排好序的列表，按照列表中的值重新從列表中讀取對應的數據輸出。即從磁盤讀取排序字段，在 buffer 進行排序，再從磁盤取其他字段。如果使用雙路排序，取一批數據要對磁盤進行兩次掃描，眾所周知，I/ O 操作是很耗時的，因此在 MySQL4.1 以后，出現了改進的算法：單路排序。
單路排序：從磁盤中查詢所需的列，按照 order by 列在 buffer 中對它們進行排序，然后掃描排序后的列表進行輸出。它的效率更高一些，避免了第二次讀取數據，并且把隨機 I / O 變成了順序 I /O，但是會使用更多的空間，因為它把每一行都保存在內存中了。但當讀取數據超過 sort_buffer 的容量時，就會導致多次讀取數據，并創建臨時表，最后多路合并，產生多次 I /O，反而增加其 I / O 運算。
解決方式：
增加 sort_buffer_size 參數的設置。
增大 max_length_for_sort_data 參數的設置。
4. 提升 order by 速度
在使用 order by 時，不要用 select *，只查詢所需的字段。因為當查詢字段過多時，會導致 sort_buffer 不夠，從而使用多路排序或進行多次 I / O 操作。
增加 sort_buffer_size。
增加 max_length_for_sort_data。
5. 優化 group by
group by 與 order by 很類似，其實質是先排序后分組，遵照索引創建順序的最佳左前綴法則。當無法使用索引列的時候，也要對 sort_buffer_size 和 max_length_for_sort_data 參數進行調整。注意 where 高于 having，能寫在 where 中的限定條件就不要去 having 限定了。
看完上述內容，你們對 MySQL 數據庫 ORDER BY 優化是怎樣的呢有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。
