說起優化排序的工作，本人菜鳥一枚，如果百度找到的我想學習請轉道，因為我也不能保證一定准確。
如果發現我寫的不好請留言，留下微信，我給你發紅包
這塊的學習領域在高性能mysql中175頁使用索引排序，查詢官方的總比我寫的好一些
前言：在索引中，每種索引的存儲方式都是不同在，在innodb中，存儲方式可以概括為
存儲事務id ，回滾事務id，主鍵索引，還有其他列的索引
因為有其他列的索引存在的關系，加入查詢的條件在索引的范圍以內，它就可以不用回表進行查詢，
先提提回表的消耗，它會產生隨機的磁盤io，相對於全表查詢來說他的性能會更差，但是加入產生了索引情況
為查詢字段全部包含的，他就會產生覆蓋索引，在索引中結束了查詢，尤其是myisam中，bree tree 索引可以進行
壓縮的情況，他會讓查詢的速度更快，然后where條件和查詢字段還有order條件中每個階段的索引都是非常重要的
order by 中的字段順序其實也是很重要的，但是可能
mysql中如果使用排序即 order by 可能會存在使用using temproary 或者filesort 的情況，將會影響到查詢性能，
現在有一些特殊的情況會使得排序查詢不使用filesort
首先order by中涉及的字段需要從最左相對索引，進行挨個判斷，不能存在索引之外字段進行排序，
然后符合排序（默認是升序）的如果需要使用降序，有一種設計方案，將字符串翻轉，或者取反，加入使用的是多表查詢，
orderby 中只能包含關聯的第一張表，使用到的索引中的從左側開始的字段，
也有例外 ，當使用了左側的數據使用了常量，數據也可以使用下一個字段
打字太累了，搬動這個吧
以上的理論
這個是我自己進行模擬測試的情況
例如
目前存在索引
因為需求的原因，有許多項目出現要優化倒序的排序
可以在創建索引的時候進行desc 例如
ALTER TABLE `wd_announcement`
ADD INDEX `aa` (`role_id` desc) ;
然后進行explain 查詢是否使用了臨時表