GROUP BY 1 强制全表扫描，因其为常量分组，无法利用索引有序性，MySQL 必须读取所有行完成聚合；替代方案是直接使用聚合函数，无需 GROUP BY。
GROUP BY 1 为什么强制全表扫描
因为常量分组（如 GROUP BY 1、GROUP BY 'a'）无法利用任何索引的有序性，MySQL 必须读取所有行才能确认“只有一组”，所以只能走全表扫描 + 临时表聚合路径。
哪些常量写法会触发 type=ALL 和 Using temporary
以下写法看似简单，实则完全放弃索引能力：
-
GROUP BY 1或GROUP BY 'x'：分组键与数据无关，引擎无法跳过任何行 -
GROUP BY (SELECT 1)：子查询结果仍是常量，且引入额外执行计划分支 -
GROUP BY CASE WHEN 1=1 THEN 'all' END：表达式恒定，优化器识别为常量分组
这些都会在 EXPLAIN 中显示 type=ALL，且 Extra 含 Using temporary —— 即使表只有 10 行，逻辑上也得扫一遍。
为什么不能像 ORDER BY 一样“优化掉”
ORDER BY 常量（如 ORDER BY 1）可能被优化器忽略或降级为无序输出，但 GROUP BY 常量不同：
MiniMax 媒体生成
下载
一款AI音频处理工具，主要用于MiniMax统一媒体生成技能，用于TokenPlan工作流。当用户要求生成音频、语音、TTS、旁白、图片、插图、姿势等媒体内容时使用，适合需要提升相关任务效率的用户。
- 它仍需完成聚合语义：
COUNT(*)要统计总行数，MAX(col)要遍历所有值找最大 - MySQL 不会把
GROUP BY 1等价于“不分组”，因为 SQL 标准要求它产生单行结果集，且必须保证聚合函数正确性 - 没有索引能提供“全表最小值”或“全表计数”的元数据，所以无法 shortcut
替代方案：用聚合函数直接代替 GROUP BY 常量
如果你只是想算总数、最大值等单值结果，根本不需要 GROUP BY：
- 错：
SELECT COUNT(*), MAX(price) FROM orders GROUP BY 1 - 对：
SELECT COUNT(*), MAX(price) FROM orders
后者无需分组逻辑，优化器可走索引统计（如 count(*) 可能用 INFORMATION_SCHEMA 或聚簇索引行数估算），甚至命中覆盖索引的 MIN()/MAX() 松散扫描（前提是索引存在且顺序匹配）。
最易被忽略的一点：开发常以为 GROUP BY 1 是“语法糖”，但它在执行层和优化层都无特殊处理——它就是明确告诉 MySQL：“请把整张表当作一个桶来装”。
