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 写得不好，而在业务上误把报表逻辑塞进了交易链路。
