ORDER BY在GROUP BY后没走索引，除非二者字段完全一致且顺序相同；否则必触发Using filesort，因聚合函数值不存于索引中，MySQL需先计算再排序，无法复用索引顺序。

ORDER BY在GROUP BY之后没走索引

MySQL无法复用GROUP BY的索引顺序做后续排序，除非ORDER BY字段和GROUP BY字段完全一致且顺序相同。比如GROUP BY user_id后接ORDER BY user_id能走索引；但换成ORDER BY COUNT(*) DESC或ORDER BY amount_sum，就必然触发Using filesort——执行计划里Extra列会明确标出。

常见错误现象：聚合结果只有几千行，但排序耗时数秒甚至更久。这不是数据量问题，而是MySQL被迫把聚合结果写入临时表，再启动外部归并排序（磁盘IO + 多路归并），哪怕sort_buffer_size调大也难缓解。

• 检查执行计划：EXPLAIN SELECT ... GROUP BY ... ORDER BY ...，重点看Extra是否含Using filesort或Using temporary; Using filesort
• 别指望ORDER BY COUNT(*)能走索引——聚合函数本身不存储在索引中，MySQL必须先算完再排
• 如果业务允许，优先去掉ORDER BY；否则必须接受“排序发生在聚合之后”这个事实，不能靠索引跳过

复合索引设计错位导致ORDER BY失效

即使你建了INDEX idx_user_amount (user_id, amount)，当语句是SELECT user_id, SUM(amount) FROM t GROUP BY user_id ORDER BY SUM(amount) DESC时，该索引依然无法支撑排序。因为SUM(amount)不是索引中的原始值，MySQL仍需回表或扫描全部分组结果再计算、再排序。

真正能覆盖排序的索引，只对ORDER BY字段本身有效，且要求它出现在索引最右端，并满足最左前缀原则。但GROUP BY + ORDER BY混合场景下，索引很难两全。

• 若ORDER BY字段是普通列（非聚合结果），比如ORDER BY status，可尝试建INDEX (status, user_id, amount)，让status在最左，但前提是WHERE条件也用到status
• 若ORDER BY依赖聚合结果（如COUNT(*)、SUM(x)），索引完全无效，只能靠应用层排序或预计算统计表
• MySQL不支持“按聚合值排序走索引”，这是引擎限制，不是配置或写法问题

关联查询后分组再排序，优化器误选执行路径

典型症状：子查询单独跑GROUP BY只要1秒，一加上JOIN维度表+ORDER BY就飙升到30秒以上。根本原因是优化器可能选择“先关联后分组”，把百万级明细和维度表全量连接，生成巨大中间集，再分组、再排序。

这种误判在SQL Server可用FORCE ORDER压制，在MySQL则更依赖写法引导。强行用LEFT JOIN或显式物化子查询（加AS别名并确保无歧义）有时能迫使优化器先聚合。

• 把聚合逻辑封装进派生表（即子查询带别名），并确保外层JOIN只基于该小结果集，而非原始大表
• 避免在ON条件中使用函数或表达式，否则优化器可能放弃使用索引驱动关联
• 维度表上的关联字段必须有索引，否则即使聚合结果很小，JOIN本身也会变慢

排序结果集过大，触发磁盘临时文件

当GROUP BY输出的行数超过sort_buffer_size能容纳的范围，MySQL会将部分数据写入磁盘临时文件，再通过外部归并排序完成。此时ORDER BY耗时与磁盘IO强相关，响应时间变得不可预测。

注意：这和“全表扫描慢”不同，它是聚合完成后的二次开销。即使rows显示只扫了几千行，只要排序数据量超限，照样慢。

• 可通过SHOW VARIABLES LIKE 'sort_buffer_size';查看当前设置，默认通常256KB～2MB，对几千行聚合结果往往不够
• 增大sort_buffer_size仅对单个连接生效，且不能设得过高（易引发内存争抢），线上谨慎调整
• 更稳妥的做法是限制返回条数（加LIMIT），或把排序逻辑移到应用层——毕竟几千行在内存里快排比数据库磁盘归并快得多

实际中最容易被忽略的一点：你以为在优化ORDER BY，其实瓶颈早就在GROUP BY阶段埋下了。如果分组本身已触发Using temporary，那后面无论怎么调ORDER BY，整体都快不了。务必先确认GROUP BY是否已走索引分组（Using index for group by），再谈排序优化。