降序索引

做的事：两列排序方向不一样的ORDER BY

customer_id升序、created_at降序，这种混合方向在业务里很常见（比如按客户分组、组内按时间倒序）。

代码SELECT customer_id, created_at FROM orders WHERE customer_id BETWEEN 1 AND 5000 ORDER BY customer_id ASC, created_at DESC;

验证：没有降序索引时，真实还是要单独排一次序

-> Sort: orders.customer_id, orders.created_at DESC
    -> Index range scan on orders using idx_cust ...

虽然idx_cust已经按customer_id排好了序，但索引内部created_at这一列存的是升序，和查询要的降序方向不一致，MySQL没法直接利用索引顺序，只能先按索引取出数据，再单独做一次Sort。

验证：建一个方向完全匹配的复合索引，Sort真实消失了

代码CREATE INDEX idx_cust_created_desc ON orders(customer_id ASC, created_at DESC);

-> Filter: (orders.customer_id in (100,200,300))
    -> Covering index range scan on orders using idx_cust_created_desc ...   ← 没有Sort了

索引定义里显式声明了customer_id ASC, created_at DESC，这个方向组合和查询要的ORDER BY完全一致，MySQL真实可以直接按索引的物理存储顺序读出数据，Sort这一步真实从执行计划里消失了，直接变成Covering index range scan（顺带还是个覆盖索引，不用回表）。

验证：真实的耗时差距，1.5万行数据上约2.5倍

没有降序索引，走Sort：       64177 微秒 (约64.2毫秒)
有匹配方向的降序索引：       26036 微秒 (约26.0毫秒)   ← 快约2.5倍

分步演示：混合方向ORDER BY，有没有降序索引的区别

每一步都是本文上面用EXPLAIN FORMAT=TREE和真实计时跑出来的原始结果。