group by 慢主因是未走索引导致 using temporary 或 using filesort；应建覆盖索引（group by列+非聚合字段+聚合字段），避免函数分组，慎用sql_big_result，高频场景优先用汇总表预计算。
GROUP BY 为什么慢？先看执行计划里有没有 Using filesort 或 Using temporary
MySQL 在执行 GROUP BY 时，如果无法利用索引完成分组，就会创建临时表 + 排序，这两个标志一旦出现在 EXPLAIN 的 Extra 列里，基本就是性能瓶颈源头。常见诱因包括：分组字段没索引、索引不覆盖 SELECT 中的非聚合列、用了函数包装分组字段（如 YEAR(created_at)）、或 GROUP BY 和 ORDER BY 字段不一致。
实操建议：
- 用
EXPLAIN FORMAT=TRADITIONAL SELECT ... GROUP BY ...确认执行路径，重点关注type（是否为range/ref）和key（是否命中索引） - 避免在
GROUP BY子句中对字段做计算或类型转换，比如把GROUP BY user_id写成GROUP BY CAST(user_id AS CHAR) - 若必须按表达式分组（如按日期天分组），优先建生成列 + 索引：
ALTER TABLE orders ADD COLUMN order_date DATE AS (DATE(created_at)) STORED;</code><br><pre class="brush:php;toolbar:false;">CREATE INDEX idx_order_date ON orders(order_date);
复合索引怎么建才让 GROUP BY 走索引？顺序必须匹配分组+聚合字段
MySQL 只有在索引的最左前缀能完全覆盖 GROUP BY 所有列时，才可能避免临时表。但光“覆盖”还不够——如果 <code>SELECT 里还有非聚合字段（比如 SELECT user_id, MAX(amount), name FROM orders GROUP BY user_id），那 name 也得进索引，否则仍会回表甚至退化为临时表。
实操建议：
- 理想索引结构 =
GROUP BY列（顺序严格一致） +SELECT中所有非聚合字段（顺序随意，但建议放后面） + 被聚合字段（可选，用于覆盖索引减少回表） - 例如：查询
SELECT dept, AVG(salary), COUNT(*) FROM emp GROUP BY dept，建INDEX idx_dept_salary (dept, salary)即可；但如果查的是SELECT dept, AVG(salary), manager_name，就得建INDEX idx_dept_mgr_sal (dept, manager_name, salary) - 注意：
TEXT/BLOB类型不能直接建索引，若分组字段是这类类型，必须转成前缀索引（如name(50)），但前缀索引无法用于精确分组，慎用
用 SQL_BIG_RESULT 提示强制走临时表？多数时候是反模式
SQL_BIG_RESULT 是 MySQL 的优化器提示，告诉服务器“结果集很大，别用临时表缓存中间结果，直接用磁盘排序”。但它不会加速 GROUP BY，反而常导致更慢——因为绕过了内存哈希聚合，强制走外部排序。只有当分组键极多、内存不足且你确认磁盘 I/O 比哈希冲突更可控时，才考虑它。
实操建议：
- 默认不要加
SQL_BIG_RESULT；先检查tmp_table_size和max_heap_table_size是否太小（默认通常 16MB），适当调大可让临时表留在内存 - 真正该用提示的是
SQL_SMALL_RESULT（暗示结果小，可用内存哈希），但现代 MySQL（8.0+）已能较好自动判断，手动提示收益有限 - 如果发现
Created_tmp_disk_tables值持续上升，优先优化索引或拆分查询，而不是加提示
替代方案：物化视图思路 —— 用汇总表 + 定时更新扛住高频分组查询
当 GROUP BY 查询固定、数据变更不频繁（如按日统计订单数）、且响应时间要求严苛时，硬优化 SQL 效果有限。这时候不如放弃实时分组，改用预计算。
实操建议：
- 建一张汇总表，如
daily_sales_summary(date, product_id, total_amount, order_count)，用INSERT ... SELECT ... GROUP BY每日凌晨跑一次 - 写操作量大的场景，可用触发器或应用层双写维护汇总表，但要注意事务一致性（推荐用消息队列异步更新）
- 查询时直接查汇总表，
WHERE date = '2024-06-01'+ 主键查询，毫秒级返回，彻底规避GROUP BY开销
真正难的不是加索引或调参数，而是判断“这个分组查询到底该不该实时做”。很多线上慢查，根源不在 SQL 写得不好，而在业务上误把报表逻辑塞进了交易链路。
