group by是否走索引的关键判据是explain中extra列是否出现using temporary；若出现，说明索引未生效，需建符合“where等值字段→范围字段→group by字段→聚合字段”顺序的联合索引，并确保字段顺序与分组子句完全一致。
GROUP BY字段一多，查询就卡住不是因为写法错，而是MySQL被迫用磁盘临时表硬算——Using temporary和Using filesort出现在EXPLAIN的Extra列里，就是确诊信号。
怎么一眼看出GROUP BY是否真走索引？
别只看key列有没有索引名，重点盯Extra：只要出现Using temporary，说明索引对分组完全没起作用。常见假象包括：
-
type是index或ALL，但Extra里没Using where→ WHERE条件根本没进索引，过滤被拖到分组后 -
key_len异常大（比如VARCHAR(255)字段只查前10个字符，key_len却显示765）→ 索引定义和实际查询不匹配 - 索引字段顺序和
GROUP BY子句不一致，比如索引是(status, user_id)，却写GROUP BY user_id, status→ 松散索引扫描直接失效
联合索引到底该怎么建才管用？
不是把所有字段堆进去就行，必须按「WHERE强过滤字段 → WHERE范围字段 → GROUP BY字段 → SELECT聚合字段」顺序排。例如这条语句：
SELECT region, device_type, COUNT(*) FROM logs WHERE app_version >= '5.0' AND dt = '2026-08-25' GROUP BY region, device_type;
对应索引应为：INDEX(dt, app_version, region, device_type)。原因：
-
dt是等值过滤、基数低，放最左；app_version是范围条件，紧随其后 -
region和device_type是分组键，必须按顺序跟上，才能触发松散索引扫描 - 如果还要
AVG(response_time)，就把response_time加到索引末尾，形成覆盖索引，避免回表
字段太多又不能删，怎么压降分组维度？
硬扛10+字段分组等于主动放弃性能控制。更可行的是分层压缩：
- 第一层：只留1–2个高价值低基数字段，如
GROUP BY hour, region_id，这部分建好索引后基本不触发临时表 - 第二层：其余字段（如
utm_source、campaign_id）不参与物理分组，改用JSON_OBJECTAGG(utm_source, COUNT(*))聚合成单字段（MySQL 5.7用GROUP_CONCAT(CONCAT(utm_source, ':', COUNT(*)))模拟，但注意group_concat_max_len限制） - 第三层：前端真要展开明细？别塞进同一SQL，改用异步导出或带
OFFSET/LIMIT的分页拉取
为什么维度表预关联比现场JOIN更稳？
原始表按user_id, region, device_type, os_version, app_channel五字段分组，哪怕全建索引，MySQL仍大概率触发Using temporary+Using filesort——因为索引无法同时满足高基数字段的物理有序性与多维过滤的局部性。而维度表（如dim_user、dim_device）天然低基数、稳定、带业务语义，把JOIN提前做完，就能把GROUP BY压缩到1–2个主键字段上。
关键点在于维度表不能随便建：
- 字段必须是业务可解释的归类结果，比如
region不能是原始IP，得是预计算好的'华东'/'华北' - 主键建议用代理键（
region_id,os_id），避免JOIN时字符串比较开销 - 必须加唯一约束：
UNIQUE KEY uk_region_name (region_name)，否则JOIN可能产生笛卡尔积 - 若维度值缓慢变化（SCD Type 2），JOIN条件里务必带上生效时间，否则统计口径会漂移
真正难啃的是高基数字段直接进GROUP BY，比如email、ip_address、长VARCHAR拼接字段——这种场景下，再调tmp_table_size也救不了，要么降维（提取域名、IP段），要么换引擎（ClickHouse/StarRocks），没有中间路线。
