explain中key有值但extra含using filesort，说明降序索引仅用于查找而未用于排序：根本原因是where条件未提供最左列等值匹配（如status = 1），或order by字段顺序/方向与索引定义不严格一致（如索引为(a asc, b desc)却执行order by a desc, b desc），或存在函数、范围查询等导致排序能力中断。
为什么EXPLAIN里key有值但Extra还有Using filesort？
说明降序索引没真正用于排序，只是被当作普通查找索引用了。MySQL 8.0不会因为索引含DESC就自动适配ORDER BY方向——必须逐列对齐。
-
WHERE条件没提供索引最左列的等值匹配（=或IS NULL），比如建了INDEX(status, created_at DESC)，但查询写WHERE status > 1或直接省略WHERE，created_at DESC部分就失效 -
ORDER BY列顺序或方向和索引定义不严格一致：索引是(a ASC, b DESC)，只认ORDER BY a, b DESC；写成ORDER BY a ASC, b DESC通常可识别，但ORDER BY a DESC, b DESC就完全不匹配 - 查询用了函数或表达式，如
ORDER BY DATE(created_at) DESC，任何索引都无效，必须改用范围条件+原始字段
怎么写CREATE INDEX才能让降序索引生效？
语法上加DESC只是第一步，关键在列序设计和业务查询对齐。
- 等值过滤列放前面、排序列放后面：
CREATE INDEX idx_status_created ON orders (status, created_at DESC)对应WHERE status = 'done' ORDER BY created_at DESC - 多列混合方向必须按实际排序需求写死：
CREATE INDEX idx_a_b ON t (a DESC, b ASC)只加速ORDER BY a DESC, b ASC，不能复用到ASC, ASC或DESC, DESC - 避免单列
DESC索引用于纯ORDER BY x DESC：优化器常不选反向扫描，尤其小表或统计不准时；优先考虑带等值WHERE的联合索引 - MySQL 8.0.12+才支持主键中用
DESC；之前版本即使写PRIMARY KEY (id DESC)也会被忽略
为什么建了降序索引反而变慢？
不是bug，是物理存储和维护代价的真实体现。
- 空间翻倍：
INDEX(a ASC)和INDEX(a DESC)是两套独立B+树，InnoDB不复用；混合方向索引如(a ASC, b DESC)也不能替代(a DESC, b ASC) - 写入开销增加：每次
INSERT/UPDATE都要按反向规则编码键值，高并发写入表会感知到轻微延迟 - 优化器误选：当统计信息过期，或查询含
OR、IN（低版本）、函数时，降序索引可能被跳过，且无法fallback到升序索引，直接退化为全表扫+filesort -
NULL值语义变化：在DESC索引中NULL排最前（视为最小值），和ASC相反，可能造成分页结果错位
如何确认降序索引真正在跳过filesort？
光看EXPLAIN的key字段远远不够，必须盯紧三处输出。
-
Extra列必须为空或仅含Using index，绝不能出现Using filesort或Using temporary -
type应为ref、range或index，而非ALL；rows值应显著小于总行数（比如从百万降到几千） - MySQL 8.0.20+可用
EXPLAIN FORMAT=TREE，直接看执行计划里有没有-> Sort节点；没有则表示跳过 - 覆盖查询更稳妥：
SELECT status, created_at FROM orders WHERE status = 'done' ORDER BY created_at DESC搭配INDEX(status, created_at DESC)，能同时满足过滤、排序、覆盖，避免回表打乱有序性
最容易被忽略的是：范围查询（>、BETWEEN、IN在低版本）会直接切断排序能力传递，此时降序索引只剩查找价值，排序仍要filesort。
