GROUP BY性能问题主因是索引缺失，需先用EXPLAIN检查Using filesort或Using temporary；优先创建与GROUP BY顺序一致的联合索引，再酌情调大tmp_table_size等参数或加SQL_BIG_RESULT提示。
GROUP BY慢到卡住，先看执行计划里有没有Using filesort或Using temporary
这两个提示是信号灯：说明MySQL没走索引做分组，而是在内存或磁盘上硬排序+临时表。哪怕数据只有百万级，Using temporary一出现，查询就大概率从毫秒掉到秒级甚至更久。
实操建议：
- 用
EXPLAIN FORMAT=TRADITIONAL SELECT ... GROUP BY ...确认是否有那两个提示 - 如果
type是ALL或index（而非ref/range），基本等于没走有效索引 - 注意
key_len是否合理——比如字段是VARCHAR(255)但只用了前10个字节，key_len却显示765，说明索引定义可能没对齐实际查询条件
给GROUP BY字段建索引，但别盲目加单列索引
单列索引对GROUP BY a有用，但对GROUP BY a, b几乎无效；真正起效的是**最左前缀匹配的联合索引**，且顺序必须和GROUP BY子句完全一致。
实操建议：
- 建索引优先按
GROUP BY字段顺序来，例如GROUP BY user_id, status→ 建INDEX idx_group (user_id, status) - 如果同时有
WHERE条件，把过滤性强的字段放前面，比如WHERE status = 'active' GROUP BY user_id，那INDEX idx_where_group (status, user_id)比(user_id, status)更优 - 避免在
GROUP BY字段上用函数，如GROUP BY DATE(created_at)会让索引失效；改用范围查询+冗余日期字段更稳
大表GROUP BY时tmp_table_size和max_heap_table_size不够用
MySQL默认把小临时表放内存，超限就落盘成MyISAM临时表，I/O直接拖垮性能。常见现象是SHOW PROCESSLIST里看到Copying to tmp table on disk。
实操建议：
- 查当前值：
SELECT @@tmp_table_size, @@max_heap_table_size;，默认通常才16MB - 调大要同步改两个参数，且
max_heap_table_size不能小于tmp_table_size - 线上调整建议分步：先设为64M观察，再逐步到128M或256M；但别超过物理内存20%，否则OOM风险陡增
- 注意：该配置只影响单条查询的临时表，不解决索引缺失的根本问题
用SQL_BIG_RESULT提示让优化器提前走磁盘临时表
听起来反直觉，但当预估分组结果集很大（比如千万行唯一键）时，优化器默认试图全放内存，反而频繁触发落盘、重分配。这时主动告诉它“这结果肯定大”，它会跳过内存试探，直接用更稳定的磁盘临时表流程。
实操建议：
- 在
SELECT后加SQL_BIG_RESULT提示，例如：SELECT SQL_BIG_RESULT user_id, COUNT(*) FROM log GROUP BY user_id - 适用场景明确：分组键基数极高（接近行数）、且你确定不会OOM（已调大
tmp_table_size） - 别滥用：对小结果集加这个提示，反而多一次磁盘初始化开销
- 验证是否生效：看
EXPLAIN的Extra列是否出现Using temporary; Using filesort（注意，这是预期行为，不是错误）
最常被忽略的一点：索引能解决80%的GROUP BY性能问题，但很多人在没确认EXPLAIN结果前就急着调参或加提示——参数和提示只是补救，不是替代索引的设计依据。
