ORDER BY字段顺序必须与联合索引列顺序严格一致，即仅支持最左前缀匹配（如索引(a,b,c)支持ORDER BY a、a,b或a,b,c），跳过中间字段（如b或a,c）或方向不一致（如a ASC,b DESC但索引为a ASC,b ASC）均导致Using filesort。
ORDER BY字段顺序必须和联合索引列顺序严格一致
MySQL只有在ORDER BY的字段顺序与联合索引定义顺序完全匹配（或满足最左前缀）时，才能直接利用索引有序性返回结果，避免Using filesort。比如查询ORDER BY col1, col2，索引必须是INDEX(col1, col2)，而不是INDEX(col2, col1)或两个单列索引。
常见错误现象：EXPLAIN输出中Extra列出现Using filesort；即使type显示index或ref，排序仍走额外步骤。
- 索引
(col1, col2, col3)支持ORDER BY col1、ORDER BY col1, col2、ORDER BY col1, col2, col3 - 不支持
ORDER BY col2、ORDER BY col2, col3、ORDER BY col1, col3（跳过col2） - 也不支持
ORDER BY col1 DESC, col2 ASC（方向不一致），除非 MySQL 8.0+ 显式建了(col1 DESC, col2 ASC)
WHERE条件中的等值列必须作为联合索引最左前缀
当查询带WHERE时，要让排序走索引，WHERE里的等值条件字段得“扛起”索引最左边的位置。比如WHERE status = 'active' ORDER BY created_at，索引就得是INDEX(status, created_at)，不能反过来。
容易踩的坑：
-
WHERE col1 IN (1,2,3) ORDER BY col2→ 无法用(col1, col2)索引排序，因为IN对col1是范围语义，col2在索引中不再有序 -
WHERE col1 > 100 ORDER BY col2→ 同样失效，范围查询后索引右侧字段失去排序能力 -
WHERE col1 = 1 AND col2 > 10 ORDER BY col3→col3也无法参与索引排序
JOIN场景下右表排序字段必须和关联字段共用联合索引
如果ORDER BY字段来自JOIN的右表（如LEFT JOIN orders ON u.id = o.user_id ORDER BY o.created_at），那orders表上必须有覆盖user_id和created_at的联合索引，且user_id在前。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
原因：MySQL需要先根据user_id快速定位匹配行，再在这些行内部按created_at天然有序读取——这只有INDEX(user_id, created_at)能提供。
- 错例：
INDEX(created_at)或INDEX(created_at, user_id)都无法用于该排序 - 扩展情况：若还有
WHERE o.status = 'paid'，索引应为INDEX(user_id, status, created_at)，且status必须是等值过滤 -
INNER JOIN两边都可能驱动排序，但右表索引结构要求不变
覆盖索引 + 排序字段方向匹配可进一步减少回表和IO
如果查询只涉及索引列（如SELECT id, col1, col2 FROM t ORDER BY col1, col2），建INDEX(col1, col2, id)能让MySQL直接从索引B+Tree叶子节点顺序读取，既免filesort又免回表。
MySQL 8.0+支持显式降序索引，对高频ORDER BY ... DESC场景更友好：
-
ALTER TABLE t ADD INDEX idx_col1_desc (col1 DESC);比默认升序索引在ORDER BY col1 DESC时更稳定 - 多列方向混合也支持：
INDEX(col1 ASC, col2 DESC)能完美匹配ORDER BY col1 ASC, col2 DESC - 旧版本只能靠
ASC索引硬扛DESC，性能波动大，尤其数据量大时
真正难处理的是“范围条件 + 多列排序 + 深分页”的组合，这时候即使索引结构全对，优化器也可能因成本估算放弃走索引排序——得结合optimizer_trace确认实际决策路径。
