GROUP BY多列时ORDER BY变慢，因数据库不保证分组结果顺序，显式排序需聚合后额外执行；须建匹配列序的联合索引（如GROUP BY a,b ORDER BY a,b建索引(a,b)），避免Using filesort。
GROUP BY 多列时 ORDER BY 为什么变慢？
因为数据库默认不保证 GROUP BY 结果的顺序，一旦你显式加了 ORDER BY，引擎就得在聚合之后额外做一次排序——哪怕排序字段全在 GROUP BY 列表里。MySQL 8.0+ 和 PostgreSQL 都会这样，不是 bug，是语义要求。
用索引覆盖 GROUP BY + ORDER BY
核心思路：让索引同时满足分组和排序需求，避免二次排序。关键看索引列顺序是否匹配 GROUP BY 和 ORDER BY 的组合。
- 如果写的是
GROUP BY a, b ORDER BY a, b，建索引(a, b)就够用 - 如果是
GROUP BY a, b ORDER BY b, a，(a, b)索引无效，必须建(b, a) - 含函数或表达式（如
ORDER BY UPPER(name)）时，普通 B-tree 索引不生效，得用函数索引（PostgreSQL 支持CREATE INDEX ON t ((UPPER(name)))；MySQL 8.0+ 支持函数索引但需虚拟列）
SELECT 中非 GROUP BY 字段引发隐式排序
常见陷阱：SELECT a, b, MAX(c) FROM t GROUP BY a, b ORDER BY a 看似只按 a 排，但优化器可能因执行计划选择先按 a,b 分组再排，最终仍触发全量排序。尤其当 b 值分布稀疏、MAX(c) 计算开销大时更明显。
- 确认执行计划中是否有
Using filesort（MySQL）或Sort节点（PostgreSQLEXPLAIN输出） - 若只需按
a排序，且b是确定性衍生字段（比如b = FLOOR(a/10)），可考虑提前物化或用子查询隔离排序逻辑 - 避免在
SELECT列表里混入非聚合、非分组字段（违反 SQL 标准，MySQL 兼容模式下允许但行为不可控）
小数据量别硬扛，用应用层归并更稳
当分组后结果集稳定在几千行以内，且排序逻辑简单（比如按某数值降序），与其折腾复合索引或改写 SQL，不如把 GROUP BY 拆出来，去掉 ORDER BY，在应用层用 sorted() 或 Arrays.sort() 处理。省去数据库排序内存压力，也绕过索引维护成本。
- 注意：应用排序无法利用数据库的流式返回，需加载全部结果到内存
- 适合 OLAP 场景中“导出报表前最后一步排序”，不适合高并发实时接口
- Go/Python/Java 都有高效原生排序，比数据库对小集合排序快得多，特别是涉及字符串或自定义比较逻辑时
真正卡住的往往不是语法，而是没意识到 GROUP BY 和 ORDER BY 在执行计划里是两个独立阶段——中间隔着聚合结果集这个“黑盒”。查 EXPLAIN 时盯紧有没有 Using temporary; Using filesort 这类提示，比调优语句本身更关键。
