为什么在SQL查询中GROUP BY常量会导致全表扫描？-SQL-PHP中文网

group by 1导致全表扫描，因其使用常量而非索引列作为分组键，无法利用索引有序性，迫使mysql执行全表扫描并创建临时表聚合，explain中显示type: all和using temporary。

为什么在sql查询中group by常量会导致全表扫描？

GROUP BY 1 这种写法为什么等于全表扫描

因为 GROUP BY 1（或任何常量、表达式）无法提供分组键的有序性或可索引性，MySQL 只能放弃所有索引，老老实实扫完整张表，再用临时表做聚合——EXPLAIN 里必然出现 type: ALL 和 Extra: Using temporary。

常见错误现象：

写 SELECT COUNT(*), 'total' AS tag FROM orders GROUP BY 'total'，以为能“强行归成一行”，结果比直接 SELECT COUNT(*) 还慢
ORM 自动生成 GROUP BY 1（比如 Django 的 .values() 配合聚合时没传字段），查百万行表要好几秒
误以为 GROUP BY 1 是语法糖，实际它等价于按第一列的值分组，但“1”不是列名，而是字面量常量，引擎无法映射到任何索引列

真正起作用的，是分组字段是否对应索引的**可遍历前缀**。常量不指向任何物理列，自然没有顺序可言，也谈不上“复用索引排序”。哪怕表只有 10 行，优化器也会选全表扫描路径，因为它压根没别的选择。

GROUP BY 字符串字面量（如 GROUP BY 'abc'）的执行逻辑

MySQL 在解析阶段就确认 GROUP BY 'abc' 的结果恒为单一分组，但它不会因此跳过数据扫描——聚合函数如 COUNT(*) 或 SUM(amount) 仍需遍历所有行来累加。这和 SELECT COUNT(*) FROM orders 本质一样，但多了额外开销：构建单桶临时表、维护聚合状态、处理 NULL 边界。

关键区别在于：

SELECT COUNT(*) FROM orders：优化器可能走 index_merge 或直接读聚簇索引统计信息（InnoDB 的 TABLE_ROWS 是估算值，但 COUNT(*) 实际执行仍要扫）
SELECT COUNT(*), 'abc' FROM orders GROUP BY 'abc'：强制触发 Using temporary，且无法被松散索引扫描（Loose Index Scan）优化，哪怕 orders 有完美索引也没用

更隐蔽的问题是：如果语句里还带了 HAVING（比如 HAVING COUNT(*) > 1000），优化器无法提前剪枝，必须等全表扫完、聚合完，才能判断是否满足条件。

哪些“看似分组”的写法其实安全

真正能避免全表扫描的，是那些让优化器识别出“分组键可由索引顺序天然支撑”的写法。以下几种情况可以走索引：

GROUP BY user_id → 有单列索引 (user_id) 或联合索引以 user_id 开头
GROUP BY user_id, status → 有联合索引 (user_id, status)，且 WHERE 条件只含等值（如 WHERE deleted = 0）
GROUP BY DATE(created_at) 不行，但 GROUP BY created_at + WHERE created_at BETWEEN ... 可以，前提是索引包含 created_at 且顺序匹配