MySQL 8.0 新特性：Descending Indexes
一、前言
MySQL 8.0 之前的索引排序规则之前只允许 ASC 存储，创建时指定 DESC 也会被忽略，
8.0 版本为我们带来了 Descending Indexes 降序索引 👏👏👏
只能使用 ASC 索引，带来的问题就是使用 DESC 会出现更多的 using filesort 导致更多的性能损耗
二、动手实验 5.7
5.7 版本用了一张推荐系统的表，简单测试一下：
explain select similarity from new_correlation group by similarity order by similarity asc ;
此时我们是在 5.7 版本里创建了一个 idx_similarity_desc(similarity desc) 发现虽然创建的是倒序索引，但是没有效果，依然是按照 ASC 组织的。下面是使用 DESC 排序下 SQL 的执行计划：
explain select similarity from new_correlation group by similarity order by similarity desc \G
此时是在 5.7 版本下使用倒序 DESC 我们从执行计划里发现比 ASC 多了 Using temporary 和 filesort 使用临时表和文件排序，一般我们认为执行计划中有这两个的性能都不咋地，而且执行频率高的话系统 IO 的压力也会非常大，比如羽勒的内站系统数据库，配置只有 2C4G 有一个业务必须使用 DESC 排序，并发上来时 CPU 可以顶得住 IOPS 却已经到极限了。
那么到底是有多大区别呢？请继续往下看
我们使用 MySQL 执行监控计数器看看二者的区别～
下方是使用 ASC 时的计数器 Handler_read_key 较高说明查询及索引均使用正确。
下面是使用 DESC 时计数器，发现多了很多计数 Handler_read_rnd_next 从数据节点读取到下一个数据节点的次数，说明索引使用不正常，消耗的资源也是比 ASC 大许多。
我们可以看到 5.7 即使我们创建 DESC 索引但是依然是按照 ASC 排序的，某些情况下是比较消耗性能的。
三、8.0 新特性改善
我们到 8.0 中重新运行刚才的 SQL 我们添加 DESC 索引
alter table new_correlation add index idx_similarity_desc(similarity desc);
发现 Using temporary 和 filesort 已经没有了，使用了 idx_similarity_desc 索引，统计信息如下👇 创建的倒序索引不再失效。
后面我们可以根据业务情况创建合适组织顺序的索引，减少更多不必要的性能损耗。
