ORDER BY 不一定在最后执行，若索引覆盖排序字段且方向一致，则免排序；否则触发 filesort，发生在 WHERE、JOIN、GROUP BY 之后；GROUP BY 优先走索引，否则建临时表，且默认隐含 ORDER BY，需加 ORDER BY NULL 禁用。
ORDER BY 在执行计划中的实际位置
MySQL 的 ORDER BY 不一定在最后才发生。当查询能利用索引有序性时，排序会“消失”——优化器直接按索引顺序回表取数据，不触发 filesort。但只要出现以下任一情况，就会强制排序：
- 排序字段未被同一索引覆盖（例如
WHERE a=1 ORDER BY b,c，但索引是(a, b)而非(a, b, c)） - 混合 ASC/DESC（如
ORDER BY a ASC, b DESC），且索引未按该方向定义 - 对函数或表达式排序（
ORDER BY UPPER(name)） - 涉及多表 JOIN 后排序，而驱动表无法提供全局有序
用 EXPLAIN 查看 Extra 列：出现 Using filesort 就表示真正排序已发生，且发生在 WHERE、JOIN、GROUP BY 之后（除非有 ORDER BY NULL 显式抑制）。
GROUP BY 和临时表的关系
MySQL 实现 GROUP BY 主要靠两种方式：松散索引扫描（Loose Index Scan）和临时表 + 文件排序（Temporary table + filesort）。是否走索引取决于分组字段是否构成索引最左前缀，且无范围条件中断。
- 能走索引的情况：
SELECT a, COUNT(*) FROM t GROUP BY a，且有索引(a)或(a, b) - 被迫建临时表：
SELECT a, COUNT(*) FROM t WHERE b > 10 GROUP BY a，若索引是(b, a)，则因b是范围条件，a无法用于分组索引下推 -
GROUP BY默认隐含ORDER BY相同字段，想禁用需显式加ORDER BY NULL，否则即使不需要排序也会触发额外 sort
临时表类型由 tmp_table_size 和 max_heap_table_size 共同控制：内存不足时自动转成磁盘 MyISAM 表，性能陡降。
ORDER BY 和 GROUP BY 同时存在时的执行顺序
语法上 GROUP BY 写在 ORDER BY 前面，但逻辑执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。关键点在于：
-
ORDER BY字段只能是SELECT列表中的项（或其别名）、分组字段，或 聚合函数 结果；不能引用未分组又未聚合的列（否则报错sql_mode=only_full_group_by） - 如果
GROUP BY已使用索引完成，而ORDER BY又需要另一套顺序，MySQL 通常不会复用中间结果，而是对分组结果再做一次排序 - 示例：
SELECT dept, AVG(salary) AS avg_sal FROM emp GROUP BY dept ORDER BY avg_sal DESC;这里
ORDER BY avg_sal是对聚合后的结果排序，必然发生在GROUP BY之后，且无法用原始表索引加速
避免排序与分组开销的实用技巧
真正的瓶颈往往不是算法本身，而是 数据访问 路径和中间结果集大小。优先考虑减少参与排序 / 分组的数据量，而非调优 排序算法。
- 用
WHERE尽早过滤，比在HAVING中过滤更高效（HAVING是对分组后结果筛选） - 为
GROUP BY字段单独建索引，比依赖联合索引的前缀更可靠（尤其当有范围条件时） - 确认是否真需要排序：分页场景中，
LIMIT 10配合无序结果可能比全量排序快得多 - 监控
Created_tmp_tables和Created_tmp_disk_tables状态变量，突增说明临时表频繁落盘
复杂报表查询里，GROUP BY 和 ORDER BY 经常成为隐藏的性能杀手——它们不报错，但会让执行时间从毫秒级跳到秒级，而且很难通过加索引彻底解决。
