存储过程中group by执行慢的主因是未走索引或全表扫描，应先查执行计划，确保where条件前置、合理使用复合索引并及时更新统计信息。
存储过程中 GROUP BY 执行慢，先看执行计划
存储过程里跑得慢的分组统计，90% 不是语法问题，而是没走索引或扫描了全表。别急着改逻辑，先在存储过程里加 EXPLAIN（MySQL）或 SET STATISTICS IO ON（SQL Server）看实际执行计划。重点盯两件事：rows scanned 是否远大于 rows returned，以及 type 或 Operator 是否出现 ALL / Table Scan。
WHERE 条件必须写在 GROUP BY 之前
常见错误是在存储过程里先 JOIN 大表、再 WHERE 过滤、最后 GROUP BY，结果数据库被迫对几百万行做分组。正确顺序是：所有能缩小数据集的条件（尤其是时间范围、状态码、ID区间）必须放在 WHERE 子句里，且尽量靠近查询起点。
- 错例：
SELECT dept_id, COUNT(*) FROM emp JOIN dept ON emp.dept_id = dept.id GROUP BY dept_id WHERE emp.status = 'active'（部分数据库会报语法错，但逻辑上 WHERE 在 GROUP BY 后） - 对例：
SELECT dept_id, COUNT(*) FROM emp WHERE status = 'active' AND hire_date >= '2023-01-01' GROUP BY dept_id - 如果过滤字段来自关联表，把条件下推到对应
JOIN的ON子句里，比如JOIN dept ON emp.dept_id = dept.id AND dept.is_valid = 1
避免在存储过程中动态拼接 GROUP BY 字段
用 IF 或 CASE 动态决定按哪几列分组，会导致每次执行都重新编译执行计划，缓存失效。更稳的做法是：固定分组字段，用聚合函数“收拢”不需要分组的冗余字段。
- 比如要查部门下员工数 + 部门名称，但又不想在
GROUP BY里加dept_name（因为一个dept_id对应唯一名称），就写成：MAX(dept_name) AS dept_name - 多个非键字段同理：
MAX(emp_name), MAX(title), AVG(salary)，前提是业务上这些字段在组内确实一致或可取任意值 - 若字段存在多值歧义（如一个部门有不同办公地点），硬用
MAX()会掩盖数据问题，此时必须明确业务规则，而不是让 SQL “随便选一个”
大表分组前先建好复合索引
索引不是加在 GROUP BY 列上就完事。真正起效的是「WHERE + GROUP BY + SELECT 中非聚合字段」的组合索引。例如：SELECT dept_id, COUNT(*), AVG(salary) FROM emp WHERE status = 'active' GROUP BY dept_id，最优索引是：CREATE INDEX idx_emp_status_dept ON emp(status, dept_id, salary)。
- 顺序很重要：等值过滤字段（
status）放最左，然后是分组字段（dept_id），最后是需要参与计算的字段（salary）——这样能覆盖查询，避免回表 - 不要给高基数字段（如
create_time）建单独索引用于分组；日期范围查询优先考虑分区表或按天/月的索引前缀 - 定期用
ANALYZE TABLE或UPDATE STATISTICS刷新统计信息，否则优化器可能误判索引有效性
