加ORDER BY NULL仅禁用结果输出排序，不解决分组过程中的索引不匹配问题；GROUP BY仍需满足最左前缀、等值WHERE、覆盖索引等硬性条件，否则仍触发Using filesort。
MySQL 5.7+ 中 GROUP BY 本身不强制隐式排序，但只要查询中存在任何触发排序的需求（哪怕没写 ORDER BY），优化器就可能走错索引路径，最终在 EXPLAIN 里看到 Using filesort —— 这不是 bug，是索引没对上。
为什么加了 ORDER BY NULL 还是出现 Using filesort？
常见误解是：只要写了 GROUP BY ... ORDER BY NULL 就万事大吉。实际不是。
-
ORDER BY NULL只禁用“结果集输出顺序”，但不解决分组过程中的排序需求——如果GROUP BY字段本身无索引，MySQL 仍需建临时表 +filesort来完成分组 - WHERE 条件用了索引 A，
GROUP BY字段是索引 B 的非前导列，MySQL 无法复用，B 被弃用，A 又不能支撑分组，照样 fallback 到filesort - SELECT 中混入了非分组字段（如
SELECT name, COUNT(*) FROM t GROUP BY dept_id），且name不在联合索引覆盖范围内，优化器会放弃 Loose Index Scan，退化为 Tight 扫描 +filesort
GROUP BY 索引必须满足哪些硬性条件？
不是“有索引就行”，而是结构必须严丝合缝，否则 MySQL 直接无视。
- 索引类型必须是
BTREE（HASH索引完全无效） -
GROUP BY字段必须严格匹配索引最左前缀，不能跳列、不能换序；例如索引是(status, user_id, create_time)，则GROUP BY status, user_id可行，GROUP BY user_id或GROUP BY create_time都不行 - 若带 WHERE，等值条件列必须是索引前导列（如
WHERE status = 'active'），范围查询（>、BETWEEN）会让 Loose Index Scan 失效 - 聚合函数仅限
MIN()/MAX()且作用于紧邻GROUP BY后的同一索引列，否则无法触发松散扫描
GROUP BY 和 ORDER BY 共存时怎么建索引？
很多人以为建一个 (a, b) 索引就能同时服务 GROUP BY a ORDER BY b，但 MySQL 对两者的利用逻辑不同。
- 如果
GROUP BY a ORDER BY a，索引(a)足够；但如果GROUP BY a ORDER BY b，且b不是分组键，MySQL 无法复用索引做两次事，大概率触发filesort - 聚合后按计算值排序（如
ORDER BY COUNT(*) DESC）永远无法用索引加速，因为COUNT(*)是运行时计算结果，不可能被索引覆盖 - 真正能共用索引的场景是：
GROUP BY a, b ORDER BY a, b，此时建索引(a, b)即可；若还要查其他字段，得扩展成覆盖索引，比如(a, b, c, d)对应SELECT c, d, COUNT(*) FROM t GROUP BY a, b ORDER BY a, b
最容易被忽略的一点：即使你建了完美索引，只要 SQL 中 SELECT 出了非索引覆盖字段（比如加了个 SELECT * 或漏了某个 name），MySQL 就会放弃索引排序路径，转头去 filesort。别只盯着 GROUP BY 字段，整个查询的字段组合和索引是否匹配，才是关键。
