ORDER BY 使聚合查询变慢的本质是先完成GROUP BY聚合再对中间结果排序，导致额外磁盘IO和内存拷贝；若ORDER BY字段未参与分组或与索引顺序/方向不匹配，则必然触发Using temporary和Using filesort。
ORDER BY 让聚合结果排序变慢，本质是二次计算
聚合查询（如 GROUP BY + SUM()、COUNT()）本身已经产生一个压缩后的中间结果集，但加上 ORDER BY 后，MySQL 或 PostgreSQL 并不会直接在这个小结果上排序——它往往先完成聚合，再把聚合结果写入临时表，最后对临时表排序。这个“先聚后排”的流程导致额外的磁盘 IO 和内存拷贝，尤其当分组数多（比如上万组）、排序字段未索引时，Using temporary; Using filesort 就会同时出现。
GROUP BY 和 ORDER BY 字段不一致，索引完全失效
即使你为 GROUP BY 字段建了索引，只要 ORDER BY 的字段不是同一个，或者顺序/方向不匹配，优化器大概率放弃索引排序。例如：
-
SELECT dept, COUNT(*) FROM emp GROUP BY dept ORDER BY salary DESC→salary未参与分组，也没在索引中，必然Using filesort -
SELECT status, AVG(amount) FROM orders GROUP BY status ORDER BY status ASC→ 如果索引是(status)，这个能走Using index；但如果写成ORDER BY status DESC，而 MySQL 版本
聚合后数据量小，但排序仍慢？检查是否隐式类型转换
看起来只有几百行聚合结果，排序却要几百毫秒，常见原因是 ORDER BY 字段存在隐式类型转换。比如 ORDER BY created_at，但 created_at 是 VARCHAR 类型存的时间字符串，数据库必须逐行转成时间再比大小，无法利用任何索引，且排序缓冲区（sort_buffer_size）可能反复溢出到磁盘。
- 用
EXPLAIN FORMAT=TRADITIONAL看Extra是否有Using filesort，再结合SHOW WARNINGS检查是否有隐式转换警告 - 确认字段真实类型：
DESCRIBE table_name或SHOW COLUMNS LIKE 'col' - 避免在
ORDER BY中用函数，如ORDER BY DATE(created_at)—— 即使created_at是DATETIME，加函数也会让索引失效
想跳过排序又保留聚合逻辑？用 ORDER BY NULL 显式声明
很多报表场景其实不需要最终结果有序，只是 SQL 框架或 ORM 默认加了 ORDER BY。MySQL 支持 ORDER BY NULL 作为明确指令，告诉优化器“别排了”，可直接跳过排序阶段。PostgreSQL 不支持该语法，但可用 ORDER BY (SELECT NULL) 达到类似效果（需验证执行计划）。
-
SELECT user_id, COUNT(*) FROM log GROUP BY user_id ORDER BY NULL→ 可消除Using filesort - 注意：仅适用于业务确实不要求顺序的场景；如果后续还要
LIMIT取 Top-N，没排序会导致结果不可控
ORDER BY 字段没被覆盖索引包含，数据库就得重新排序——这个动作不会因为数据少就自动优化掉。 
