GROUP BY 1或常量分组必然全表扫描，因其分组键与数据无关，无法利用索引有序性，MySQL必须读取所有行确认单组并保证聚合准确性，故只能走type=ALL+Using temporary路径。
GROUP BY 1 或常量分组为什么必然全表扫描
因为 GROUP BY 1、GROUP BY 'a'、GROUP BY (SELECT 1) 这类写法，分组键与表数据完全无关，优化器无法利用任何索引的有序性。它必须读取每一行才能确认“所有数据属于同一组”，所以只能走 type=ALL 路径，并配合 Using temporary 完成聚合——哪怕表只有 5 行，逻辑上也得扫一遍。
这不是 MySQL “不够聪明”，而是 SQL 标准要求：即使结果只有一行，GROUP BY 仍需保证 COUNT(*) 统计准确、MAX(col) 找到全局最大值。没有索引能提供“全表最大值”这种元数据，所以没法 shortcut。
- 错：
SELECT COUNT(*), MAX(price) FROM orders GROUP BY 1 - 对：
SELECT COUNT(*), MAX(price) FROM orders（去掉GROUP BY，让优化器自由选择松散索引扫描或统计信息）
分组字段没索引 or 索引顺序错位
MySQL 的 GROUP BY 高效依赖索引的物理有序性。如果索引是 (status, user_id)，但你写 GROUP BY user_id，那这个索引就用不上；同理，GROUP BY user_id, status 也无法复用 (status, user_id) 索引——B+ 树不支持跳过最左列后按第二列排序。
复合索引必须严格左前缀匹配，且分组列顺序要和索引定义顺序一致。否则优化器看不到“天然分组连续性”，只能退回到全表扫描 + 内存/磁盘哈希聚合。
- 要支持
GROUP BY a, b→ 至少建INDEX(a, b) - 若还有
WHERE c = ?→ 优先建INDEX(c, a, b)，让过滤和分组一气呵成 - 别指望单列索引
INDEX(a)能撑起GROUP BY a, b，除非b是常量或有强约束
SELECT 字段超出索引覆盖范围
即使 GROUP BY 列本身有索引，只要 SELECT 中包含非分组、非聚合、且不在索引里的字段（比如 SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id），MySQL 就必须回表查 name ——而回表是随机 IO，代价高；更糟的是，优化器可能直接放弃索引，改走全表扫描 + 临时表聚合，只为一次性拿到所有数据。
判断是否真正覆盖：看 EXPLAIN 的 key 是否非 NULL，且 Extra 中**没有** Using temporary 和 Using filesort，同时 SELECT 所有字段都出现在该索引定义中。
- 要支持
SELECT user_id, status, SUM(amount)→ 索引应为(user_id, status, amount) -
TEXT或BLOB字段不能建索引，一旦出现在SELECT里，覆盖索引就失效 - 别把
name这种高频非确定字段硬塞进GROUP BY，改用ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY id DESC)子查询取最新一条
WHERE 条件没走索引，导致 GROUP BY 前就已全扫
很多人以为“我只返回 10 行，肯定快”，但执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT。如果 WHERE 没命中索引（比如用了 OR、LIKE '%abc'、YEAR(create_time) = 2026），那数据库在分组前就已经全表扫描了——后面所有优化都白搭。
尤其注意隐式类型转换：user_id 是 BIGINT，但传参写成 WHERE user_id = '12345'，字符串转数字会绕过索引，GROUP BY 自然也没机会用上。
- 把时间范围过滤写成
WHERE create_time >= '2026-01-01' AND create_time ，别用 <code>YEAR() -
OR条件尽量拆成UNION ALL，或改用IN（前提是字段有索引） - 参数化查询时，确保变量类型和字段类型严格一致，避免服务端隐式转换
真正卡住性能的，往往不是 GROUP BY 语法本身，而是它前面那层 WHERE 没拦住数据，或者后面那层 SELECT 把索引拖垮了。索引列顺序、字段类型一致性、函数滥用——这些细节不检查清楚，建再多索引也没用。
