GROUP BY触发临时表的本质是无法流式分组，即索引顺序与分组字段不一致、含范围WHERE条件或SELECT未覆盖非聚合列，导致MySQL必须全量读入临时表再归并。
GROUP BY 触发临时表的本质是“无法流式分组”
MySQL 只有在能按 GROUP BY 字段「自然有序扫描」时，才可能跳过临时表。一旦索引顺序与分组字段顺序不一致、WHERE 条件含范围查询（如 created_at > '2024-01-01'）、或 SELECT 中包含未被索引覆盖的非聚合列，优化器就无法边扫边累加，只能先读全量数据进临时表再归并——这个过程本身不涉及行锁，但会争用内存/磁盘资源，造成并发阻塞。
临时表不是“锁表”，但会引发资源级竞争
所谓“临时表锁”其实是误称。MySQL 的内部临时表默认在内存中创建（引擎为 MEMORY），由 tmp_table_size 和 max_heap_table_size 共同限制大小。当分组数据量超限，它会自动转成磁盘临时表（InnoDB 或 MyISAM），此时：
- 多个并发
GROUP BY查询可能同时申请大量磁盘 I/O，导致系统负载飙升 - 若使用
MyISAM临时表（旧版本或配置强制），会出现表级写锁，阻塞其他临时表操作 -
InnoDB临时表虽无显式锁，但大量插入+排序仍会挤占 buffer pool 和 sort buffer，间接拖慢其他查询
哪些索引能真正避免临时表？
不是加索引就行，关键看三件事：顺序、覆盖、等值前置。
- 单字段分组如
GROUP BY user_id，仅建INDEX idx_user (user_id)不够；若常带WHERE status = 'active'，应建(status, user_id)—— 等值条件必须放最左 - 多字段分组如
GROUP BY user_id, DATE(created_at)，MySQL 8.0+ 才支持函数索引INDEX idx_u_d ((user_id, DATE(created_at)))；5.7 需冗余生成列 + 普通索引 - 若
SELECT user_id, COUNT(*), MAX(amount)，索引必须包含amount（至少是前缀），否则回表触发临时表
容易被忽略的隐式排序开销
GROUP BY 默认隐式按分组字段升序排序，这和 ORDER BY 共享同一套索引逻辑。哪怕你没写 ORDER BY，只要索引顺序不匹配分组顺序（比如索引是 (a, b) 却 GROUP BY b, a），就会同时出现 Using temporary 和 Using filesort —— 这才是并发下降的主因。加 ORDER BY NULL 可禁用隐式排序，但仅当业务真不需要顺序时才安全。
