摘要：
MySQL中Union子句不支持order by的解决方法？在某些情况中，MySQL可以使用一个索引来满足ORDER BY子句，而不需要额外的排序。即使ORDER BY不确切匹配索... MySQL中Union子句不支持order by的解决方法？
在某些情况中，MySQL可以使用一个索引来满足ORDER BY子句，而不需要额外的排序。
即使ORDER BY不确切匹配索引，只要WHERE子句中的所有未使用的索引部分和所有额外的ORDER BY 列为常数，就可以使用索引。
但是，在有些情况下，MySQL不能使用索引来解决ORDER BY，尽管它仍然使用索引来找到匹配WHERE子句的行。
参考自：
MySQL如何优化ORDER BY
MySQL中一条排序语句order by是如何工作的？
MySQL长期以来对索引的建立只允许正向asc存储，就算建立了desc，也是忽略掉。
比如对于以下的查询，无法发挥索引的最佳性能。
- 查询一：
select * from tb1 where f1 = ... order by id desc;
- 查询二：
2. select * from tb1 where f1 = ... order by f1 asc , f2 desc;
那对于上面的查询，尤其是数据量和并发到一定峰值的时候，则对OS的资源消耗非常大。一般这样的SQL在查询计划里面会出现using filesort等状态。
比如针对下面的表t1，针对字段rank1有两个索引，一个是正序的，一个是反序的。不过在MySQL 8.0 之前的版本都是按照正序来存储。
按照rank1 正向排序的执行计划，
按照rank1 反向排序的执行计划，
从执行计划来看，反向比正向除了extra里多了Using temporary; Using filesort这两个，其他的一模一样。这两个就代表中间用到了临时表和排序，一般来说，凡是执行计划里用到了这两个的，性能几乎都不咋地。除非我这个临时表不太大，而用于排序的buffer也足够大，那性能也不至于太差。那这两个选项到底对性能有多大影响呢？
