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经常成为隐藏的性能杀手——它们不报错，但会让执行时间从毫秒级跳到秒级，而且很难通过加索引彻底解决。
