低基数字段GROUP BY仍触发Using temporary，是因为MySQL能否免临时表取决于数据是否能顺序扫描归并，而非分组值数量；即使status仅3种值，若无合适联合索引（如WHERE等值字段前置+GROUP BY字段紧随），优化器仍会全表扫描后建临时表分组。
低基数字段 GROUP BY 为什么还触发 Using temporary
低基数（比如 status 只有 'pending'/'paid'/'failed' 三种值）不等于低开销。MySQL 是否走临时表，关键看它能不能“顺序扫描+归并”，而不是分组后有多少行。哪怕只有 3 个分组值，只要数据在磁盘上不按 status 物理排序，MySQL 就得把所有匹配行捞出来，再建临时表做哈希或排序分组。
常见误判是：“才 3 个值，索引随便建一个就行”。但如果你只建了单列 INDEX(status)，而查询里还有 WHERE created_at > '2024-01-01'，那这个单列索引大概率被跳过——因为范围条件让优化器放弃用它做有序扫描，转而全表扫 + 临时表。
- 必须建联合索引，且
WHERE条件字段前置：例如WHERE shop_id = 123 AND created_at > '2024-01-01' GROUP BY status，索引应为(shop_id, created_at, status)，不能是(status, shop_id) - 如果
created_at是范围条件，它后面字段（如status）在 B+ 树中已失去有序性，但加在复合索引末尾仍可被用于分组——前提是前面的等值字段能精确切片 -
EXPLAIN中key显示用了索引，但Extra仍有Using temporary：说明索引只帮上了过滤，没帮上分组，物理顺序不匹配
GROUP BY status 和 SELECT status, COUNT(*) 的覆盖索引怎么建
覆盖索引不是“把所有字段塞进去”，而是让整条访问链不回表。对 SELECT status, COUNT(*) FROM orders WHERE shop_id = 123 GROUP BY status，COUNT(*) 不依赖具体列值，但 status 必须从索引中直接读出，且索引要能支撑 WHERE + GROUP BY 的联合有序性。
- 最优索引是
INDEX(shop_id, status)：等值过滤shop_id后，剩余数据天然按status排序，分组可流式归并，零临时表 - 如果加了
created_at > ...范围条件，索引必须是(shop_id, created_at, status)；此时status虽在末尾，但因shop_id等值 +created_at范围，B+ 树中满足条件的页内status仍是局部有序的，MySQL 8.0+ 可利用松散索引扫描（Loose Index Scan） - 别把
order_id或amount这类大字段加进这个索引——它们和当前查询无关，只会撑大索引体积，拖慢所有使用该索引的查询
为什么加了 (status) 单列索引，EXPLAIN 还显示 type=ALL
单列索引 (status) 在低基数场景下极易被优化器主动弃用。原因很实在：扫完整个索引树再回表，不如直接扫聚簇索引（主键）快——尤其当表行数不大（比如百万级）、且 status 分布极不均匀（90% 是 'pending'）时，优化器估算回表成本高于全表扫描。
- 执行
SHOW INDEX FROM orders确认该索引是否真实生效，而非被统计信息误导 - 运行
ANALYZE TABLE orders更新统计信息，有时旧的行数/基数估算会让优化器选错路 - 强制走索引（
USE INDEX(status)）可能反而更慢，别盲目 hint；优先补联合索引，让优化器有真正靠谱的选择 - 用
SELECT COUNT(*) FROM orders WHERE status = 'paid'单独测该索引选择性：如果返回行数占全表 40% 以上，MySQL 很可能判定它不适合驱动查询
低基数 + 高并发下 GROUP BY 的隐形瓶颈
单次查询快，不代表高并发稳。低基数字段分组看似轻量，但容易成为热点路径：多个线程同时扫描同一小段索引页（比如所有 status = 'pending' 记录集中在前几个数据页），引发缓冲池争用、自适应哈希锁冲突，甚至 InnoDB 行锁升级为间隙锁阻塞。
- 监控
SHOW ENGINE INNODB STATUS中的SEMAPHORES和TRANSACTIONS区块，看是否有大量线程卡在dict_operation_lock或trx_sys->mutex - 避免在事务中长时间持有 GROUP BY 结果；高频报表尽量走预聚合汇总表，而非实时查原表
- 如果业务允许弱一致性，考虑在从库执行这类低基数分组查询，减轻主库压力
真正卡住性能的，往往不是“分组值少”，而是“数据没按分组键排好队”——索引结构没对齐访问模式，再多的基数优化都白搭。
