在MySQL 8.0之前，即使创建索引时指定了DESC关键字，数据库实际存储的仍然是升序索引，执行倒序查询时需要通过反向扫描索引或者额外排序来得到结果，性能开销较大。MySQL 8.0正式支持降序索引，索引可以按照降序方式存储，直接匹配倒序查询的需求，大幅减少查询过程中的额外操作。
降序索引的创建方式
创建降序索引的语法和创建普通索引类似，只需要在索引字段后添加DESC关键字即可。如果是组合索引，还可以为不同字段指定不同的排序方向。
单字段降序索引
对单个字段创建降序索引的示例如下：
-- 创建测试表
CREATE TABLE user_order (
id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT NOT NULL,
order_time DATETIME NOT NULL,
amount DECIMAL(10,2) NOT NULL,
INDEX idx_order_time_desc (order_time DESC)
);
-- 插入测试数据
INSERT INTO user_order (user_id, order_time, amount) VALUES
(1, '2024-01-01 10:00:00', 99.9),
(2, '2024-01-02 11:00:00', 199.9),
(3, '2024-01-03 12:00:00', 299.9),
(4, '2024-01-04 13:00:00', 399.9);
组合降序索引
组合索引中可以混合使用升序和降序排序，例如需要按用户ID升序、订单时间降序查询的场景，可以创建如下索引：
-- 创建混合排序的组合索引 CREATE INDEX idx_user_time ON user_order (user_id ASC, order_time DESC);
降序索引的性能对比
我们通过实际查询案例对比使用降序索引和普通索引时的查询计划差异。
普通索引的倒序查询
如果只存在order_time的升序普通索引，执行倒序查询时的执行计划如下：
-- 先删除之前的降序索引，创建普通升序索引 DROP INDEX idx_order_time_desc ON user_order; CREATE INDEX idx_order_time_asc ON user_order (order_time ASC); -- 执行倒序查询 EXPLAIN SELECT * FROM user_order ORDER BY order_time DESC LIMIT 10;
此时执行计划中会显示Using filesort，说明需要额外的排序操作。
降序索引的倒序查询
重新创建降序索引后执行相同的查询：
-- 删除升序索引，重建降序索引 DROP INDEX idx_order_time_asc ON user_order; CREATE INDEX idx_order_time_desc ON user_order (order_time DESC); -- 再次执行倒序查询 EXPLAIN SELECT * FROM user_order ORDER BY order_time DESC LIMIT 10;
此时执行计划中不会出现Using filesort，查询直接通过索引扫描返回结果，性能更优。
降序索引的适用场景
降序索引并非所有场景都适用，以下场景使用降序索引能获得明显的性能提升：
- 查询中频繁使用
ORDER BY 字段 DESC的排序操作 - 组合排序中部分字段需要升序、部分字段需要降序的场景
- 分页查询中需要按倒序获取最新数据的场景，比如获取最新的10条订单记录
使用降序索引的注意事项
使用降序索引时需要注意以下几点：
- 降序索引是MySQL 8.0及以上版本的特性，低版本MySQL无法使用
- 如果查询的排序方向和索引排序方向不匹配，仍然会触发额外排序，比如索引是DESC，查询用ASC排序
- 降序索引会占用额外的存储空间，创建索引时需要评估存储成本
- 只有BTREE索引支持降序索引，HASH索引等其他索引类型不支持该特性
总结
MySQL 8.0的降序索引特性为倒序扫描场景的查询优化提供了高效的解决方案，通过合理创建降序索引，可以避免倒序查询时的额外排序开销，提升查询性能。开发者在实际使用中需要结合业务查询场景，评估是否需要创建降序索引，同时注意版本的兼容性和索引的维护成本。