摘要：
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也足够大，那性能也不至于太差。那这两个选项到底对性能有多大影响呢？
MySQL ORDER BY主键id加LIMIT限制达到一定阈值后，为何没有走预期索引而走了主键索引？
Optimizer是基于RBO和CBO综合考虑，不是一定走索引效率最高，full scan table和full scan index有时候效率会更高。
假设查询 LIMIT 1, 符合WHERE条件的数据刚插入，是走WHERE条件索引快，还是ORDER BY id主键更快？显而易见，走主键full scan index更快
