GROUP BY 不强制排序，ORDER BY 才触发排序；数据库根据数据有序性选择 HashAgg 或 SortAgg；WHERE 后数据保持原序，GROUP BY 可直接哈希分桶；ORDER BY 在 SELECT 计算后执行，成本可能远超 GROUP BY。
GROUP BY 不一定先排序，但 ORDER BY 会强制触发排序
SQL 执行时 GROUP BY 本身不隐含排序要求。你看到的“先排序”，大概率是语句里显式写了 ORDER BY，或者数据库优化器在特定条件下选择了 SortAgg 算法——这不是语法规定，而是实现策略。
比如执行 SELECT node_execution_id, COUNT(*) FROM workflow_node_executions GROUP BY node_execution_id ORDER BY COUNT(*) DESC，ORDER BY 是独立于 GROUP BY 的最后一步，它要求聚合结果必须排序，引擎就会在分组完成后补上排序操作。
HashAgg 和 SortAgg 的选择取决于数据是否已有序
现代数据库（如 MySQL、PolarDB-X）对 GROUP BY 有两种主流实现：
-
HashAgg：用哈希表分组，适合无序输入；内存占用高，但不需要预排序 -
SortAgg：假设输入已按分组列排序，逐行归并聚合；内存消耗小，但前提是数据满足顺序要求
如果 SQL 中同时有 GROUP BY a, b 和 ORDER BY a, b，优化器很可能直接走 SortAgg + 后续复用排序结果，避免重复工作。这时 EXPLAIN 里会出现 MemSort 或 MergeSort 节点。
WHERE 和 GROUP BY 之间没有排序环节
常见误解是“GROUP BY 必须先排序才能分组”，其实不然：
-
WHERE过滤后，数据仍保持原始物理/扫描顺序（除非索引天然有序） -
GROUP BY可直接基于该顺序做哈希分桶，无需重排 - 只有当分组字段上存在可用索引（如
(node_execution_id)），且优化器决定走索引扫描时，才可能顺便获得有序输出——但这属于索引特性，不是GROUP BY本身的行为
ORDER BY 放在 GROUP BY 后面，但执行时机晚于 SELECT 字段计算
逻辑执行顺序决定了 ORDER BY 是倒数第二步（LIMIT 前）：
- 它能引用
SELECT中定义的别名（如count），因为此时聚合值已经算出 - 它不能引用未出现在
SELECT或GROUP BY中的列，否则报错：Unknown column 'xxx' in 'order clause' - 如果只想要分组结果的自然顺序（比如按主键递增），不要加
ORDER BY；加了就等于告诉数据库：“我要确定的顺序”，它就必须执行排序
真正容易被忽略的是：ORDER BY 的成本可能远超 GROUP BY 本身，尤其当聚合结果集很大时。若业务只要“前 N 个最多”，应优先考虑用 HAVING 配合索引过滤，而不是靠 ORDER BY ... LIMIT 拉全量再截断。
