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 ，别用 YEAR()
• OR 条件尽量拆成 UNION ALL，或改用 IN（前提是字段有索引）
• 参数化查询时，确保变量类型和字段类型严格一致，避免服务端隐式转换

真正卡住性能的，往往不是 GROUP BY 语法本身，而是它前面那层 WHERE 没拦住数据，或者后面那层 SELECT 把索引拖垮了。索引列顺序、字段类型一致性、函数滥用——这些细节不检查清楚，建再多索引也没用。