MySQL GROUP BY默认触发排序是因为其执行需数据按分组字段有序才能线性扫描聚合；8.0.25前隐式排序，8.4 LTS已移除，但若索引不匹配，优化器仍可能因误判而启用filesort或temporary表。
GROUP BY 为什么默认会触发排序
MySQL 在 8.0.25 之前会隐式按 GROUP BY 字段排序，即使你没写 ORDER BY；这个行为被很多老代码当成“理所当然”，比如前端分页直接依赖结果顺序。但 MySQL 8.4 LTS 彻底移除了它——不是加了限制，而是优化器不再为此保留有序扫描路径。更关键的是：**即使你不想要排序，优化器仍可能“以为你要”，从而选错索引、走 Using filesort 或 Using temporary。**
显式加 ORDER BY NULL 是最轻量的关闭方式
这不是“兼容旧写法”的补丁，而是明确告诉优化器：“别排，我不需要顺序”。它不改执行计划结构，只省掉一次排序判断，对高并发查询尤其有效。
-
ORDER BY NULL必须写在GROUP BY后面，且不能和其他ORDER BY混用 - 它对所有 MySQL 5.7+ 版本都生效，不只是 8.4；在 8.4 中反而更关键，因为隐式排序已不存在，但优化器残留逻辑还在
- 如果业务真需要排序，就写明确的
ORDER BY category_id，别依赖隐式行为——否则一旦索引失效或数据分布变化，结果顺序就不可控
索引设计必须匹配 GROUP BY 字段顺序
光加 ORDER BY NULL 不够。如果索引列顺序和 GROUP BY 不一致，优化器仍会建临时表。核心是让 MySQL 能“顺着索引读，同组值天然连续”。
- 查询
SELECT category, COUNT(*) FROM t WHERE status = 1 GROUP BY category，必须建INDEX(status, category)，而不是INDEX(category)或INDEX(status) -
WHERE中的等值条件（=、IN）可前置，但范围条件（>、BETWEEN）会中断最左前缀，后续字段无法用于分组加速 - 如果还带
ORDER BY category，同一索引也能复用，避免二次排序
EXPLAIN 里出现 Using temporary 就说明索引没对上
这不是内存不够的问题，也不是 sort_buffer_size 能解决的。它代表 MySQL 正在建临时表做分组——性能拐点已经出现。
-
Using temporary和Using filesort经常一起出现，意味着既落盘又排序，延迟成倍增长 -
sort_buffer_size对 GROUP BY 是否建临时表完全无效；它只影响后续的排序阶段，而建表阶段由tmp_table_size和max_heap_table_size控制 - 真正该做的是检查三个环节是否被索引覆盖：WHERE 条件、GROUP BY 字段、SELECT 中的非聚合字段（如
MAX(price)）
最容易被忽略的一点：哪怕你加了 ORDER BY NULL，只要索引没对上，优化器照样可能放弃索引扫描，转而用 hash aggregate 或临时表——这时候“不排序”只是表面，底层开销一点没少。
