不是必须，但mysql 5.7+启用only_full_group_by时，order by字段若未出现在select列表且未在group by中，会报错；多表join中排序仅依赖对应表的覆盖索引，混用多表字段或函数包裹将失效索引。
ORDER BY 字段必须出现在 JOIN 后的最终 SELECT 列表中吗？
不是必须，但 MySQL 5.7+ 默认启用 sql_mode=ONLY_FULL_GROUP_BY（含严格排序检查），如果 ORDER BY 字段没在 SELECT 中、又没在 GROUP BY 里，会直接报错：Expression #1 of ORDER BY clause is not in SELECT list。这不是优化问题，是语法拦截。
实操建议：
- 确认是否真需要该字段排序——很多场景只是习惯性写
ORDER BY id，但实际业务只消费前 20 行，而id并不在关联结果集里；删掉它能避免隐式文件排序 - 若必须排序，优先选已出现在
SELECT中的字段，或加到SELECT列表（即使不返回给应用），避免触发Using filesort - 检查执行计划：如果
Extra列出现Using temporary; Using filesort，大概率是排序字段未被索引覆盖或未出现在输出列中
多表 JOIN 时，ORDER BY 走哪个表的索引？
MySQL 不会跨表“智能拼接”索引。它只看 ORDER BY 涉及的字段属于哪张表，并检查该表是否有**覆盖排序需求的联合索引**——注意，是“该表”，不是“驱动表”或“被驱动表”。
常见错误现象：对 t1 JOIN t2 ON t1.id = t2.t1_id 查询，写 ORDER BY t2.created_at，却只在 t2 上建了单列索引 INDEX(created_at)，结果仍走临时表排序。
实操建议：
-
t2.created_at排序，就要求t2上有能支撑排序的索引，比如INDEX(status, created_at)（如果还有WHERE t2.status = 'active'） - 避免在
ORDER BY中混用多表字段（如ORDER BY t1.name, t2.created_at），这种几乎无法走索引，必然触发Using temporary - 用
EXPLAIN FORMAT=TREE（MySQL 8.0+）看排序是否下推到物化阶段之前——如果显示"ordering_operation": "sort"在 join 之后，说明排序发生在临时结果集上，很重
为什么加了索引，ORDER BY 还是用临时表？
索引存在 ≠ 排序能用。关键要看查询条件 + 排序字段是否构成**最左前缀可下推路径**，且没有类型转换、函数包裹、NULL 安全比较等破坏索引有序性的操作。
典型踩坑点：
-
WHERE t2.type = 1 ORDER BY t2.created_at DESC，但索引是INDEX(created_at, type)——顺序反了，type无法走范围扫描，created_at的有序性失效 -
ORDER BY ABS(t2.score)或ORDER BY LOWER(t2.name)：函数导致索引无法用于排序 -
WHERE t2.status IN ('a','b') ORDER BY t2.updated_at，而索引是INDEX(status, updated_at)——IN对于多值，在某些版本中会中断排序下推 - 字符集不一致：关联字段或排序字段用了不同 collation，隐式转换让索引失效
用 STRAIGHT_JOIN 强制驱动表能绕过排序开销吗？
不能。强制连接顺序只影响数据读取路径和中间结果集大小，不改变排序执行时机。如果最终结果要按某字段全局排序，MySQL 仍得把所有匹配行捞出来再排——除非你能把排序逻辑下推到单表扫描阶段。
更务实的做法：
- 确认是否真要全局排序：分页场景（
LIMIT 20 OFFSET 10000）下，OFFSET越大，临时表越重；考虑用游标分页（WHERE id > ? ORDER BY id LIMIT 20） - 用覆盖索引减少回表：如果
SELECT *导致大量随机 IO，配合排序会放大内存压力；改用SELECT t1.id, t2.name并确保这些字段都在索引里 - 监控
Created_tmp_disk_tables和Sort_merge_passes这两个状态变量，它们比慢日志更能暴露排序是否失控
临时表和排序不是非黑即白的问题，而是层层叠加的代价：字段没索引 → 回表多 → 内存不够 → 落盘 → merge 多次。每一步都可能卡住，得一层层查执行计划，别只盯着最后一行 Using filesort。
