mysql只允许对驱动表字段用索引排序，若order by指向被驱动表字段，即使有索引也会触发using filesort；判断驱动表需看explain中rows更小、过滤性更强的表，或通过straight_join强制指定。
ORDER BY 字段不在驱动表里，MySQL 就没法用索引排序
MySQL 在 JOIN 查询中做 ORDER BY 时，**只允许对驱动表（即被选作外层循环的表）的字段直接利用索引排序**。如果 ORDER BY 指向的是被驱动表（内层表）的字段，哪怕该字段上有索引，优化器也大概率放弃索引排序，转而走 Using filesort —— 这就是你看到“排序失效”的真实原因。
比如执行：SELECT u.name, o.order_id FROM users u JOIN orders o ON u.id = o.user_id ORDER BY o.create_time DESC，即使 orders.create_time 有索引，只要 orders 是被驱动表（EXPLAIN 中 type 为 ref 或 range，且 rows 显著大于驱动表），MySQL 就无法按该索引顺序取数据，只能先拼完结果集再内存/磁盘排序。
怎么快速判断哪个是驱动表
看 EXPLAIN 输出中最关键的两列：table 和 rows。MySQL 通常选择 rows 更小、过滤性更强的表作为驱动表（尤其在没有强制 STRAIGHT_JOIN 的情况下）。但注意：这个选择受统计信息影响，不是绝对的。
- 如果
users表只有几千行，orders有百万行，users很可能被选为驱动表 - 如果
WHERE条件只作用于orders（如WHERE o.status = 'PAID'），而users无过滤条件，MySQL 可能反选orders为驱动表 —— 此时ORDER BY u.name才可能走索引 -
STRAIGHT_JOIN可以强制左表为驱动表，但要小心它绕过优化器决策，可能让性能更差
ORDER BY 字段属于被驱动表时的可行解法
不能指望 MySQL 自动用被驱动表索引排序，得换思路：
- 把排序逻辑上推到驱动表：例如改写成子查询，先在
orders表里按create_time排序并 LIMIT，再 JOINusers，这样驱动表就变成了排序后的临时结果集 - 建覆盖驱动表 + 排序字段的联合索引：比如驱动表是
users，但你要按orders.create_time排，那就得让users关联出create_time后还能走索引 —— 这通常需要冗余字段或物化关联（不推荐） - 应用层排序：当数据量可控（如分页前 100 条）、且业务能容忍延迟时，查出 ID 列表后，在应用里查详情并排序，比数据库
filesort更稳 - 避免在 JOIN 结果上直接
ORDER BY被驱动表字段：这是最常踩的坑，也是最容易被忽略的设计盲点
为什么 EXPLAIN 看不出排序是否真用了索引
EXPLAIN 的 key 列只告诉你用了哪个索引做连接或过滤，**不反映排序是否用索引**。真正判断排序是否失效，得盯紧 Extra 列：
- 出现
Using filesort→ 排序没走索引，正在回内存或磁盘排序 - 出现
Using index且没有Using filesort→ 排序走了覆盖索引（极少见，仅限驱动表单表查询） - 没出现
Using filesort，但Extra为空或只有Using where→ 大概率排序由驱动表索引天然保证（如ORDER BY u.id，而u是驱动表且id是主键）
复杂 JOIN 下的排序行为高度依赖表顺序、条件分布和索引结构，不能只看有没有索引，得实测 EXPLAIN 的 Extra 和实际执行时间。
