正确做法是WHERE过滤必须写在GROUP BY之前，HAVING仅用于依赖聚合结果的筛选；索引应按WHERE条件字段+GROUP BY字段顺序创建复合索引；避免在WHERE和GROUP BY中使用函数；可借助物化视图优化高频分组查询，并通过执行计划验证优化效果。
WHERE过滤必须写在GROUP BY之前
很多人把筛选条件塞进HAVING，结果全表先分组再筛，性能断崖式下跌。比如查“经理和总裁的平均薪资”，写成GROUP BY job HAVING job IN ('MANAGER', 'PRESIDENT')，Oracle就得对所有职位做分组，哪怕其他99%的记录根本不需要。
正确做法是把条件挪到WHERE里：WHERE job IN ('MANAGER', 'PRESIDENT') GROUP BY job。这样执行计划里ROWS数会明显下降，尤其在大表上效果立竿见影。
- 只要能用
WHERE提前排除的，绝不留到HAVING -
HAVING只该用于依赖聚合结果的判断，比如HAVING COUNT(*) > 10 - 注意
WHERE中字段是否已建索引——否则过滤本身也慢
索引要覆盖WHERE + GROUP BY字段顺序
Oracle对GROUP BY的优化高度依赖索引结构。单列索引效果有限，真正起作用的是复合索引，且字段顺序必须匹配查询逻辑。
例如查询SELECT dept_id, COUNT(*) FROM emp WHERE status = 'ACTIVE' GROUP BY dept_id，推荐建索引(status, dept_id)，而不是(dept_id)或(dept_id, status)。前者能让Oracle一次索引扫描完成过滤+分组定位，避免回表和额外排序。
- 索引字段顺序：WHERE条件字段在前，GROUP BY字段紧随其后
- 如果SELECT中还包含非聚合字段（如
MAX(salary)），可考虑把该字段也加入索引末尾，构成覆盖索引 - 避免在索引字段上用函数，比如
WHERE UPPER(name) = 'JOHN'会让索引失效
别在GROUP BY里用函数或表达式
GROUP BY TRUNC(create_date)或GROUP BY SUBSTR(phone, 1, 3)这类写法，几乎必然触发Using temporary; Using filesort，因为Oracle无法直接利用原始字段索引。
临时方案是加函数索引：CREATE INDEX idx_create_date_trunc ON emp (TRUNC(create_date))；但更稳妥的做法是业务层预计算——新增create_date_day字段并索引，或用分区表按天/月切分。
- 日期类分组优先用范围条件替代函数，比如
WHERE create_date >= DATE '2026-01-01' AND create_date - 字符串截取类分组，尽量前置到ETL或应用层处理，数据库只负责简单分组
- 高基数字段（如UUID、完整邮箱）直接
GROUP BY极易撑爆内存，应先归类（如取域名、地区码）再分组
物化视图比实时GROUP BY更适配高频统计
当某个GROUP BY查询每天跑几十次、数据量又大时，硬扛实时聚合就是浪费资源。Oracle的物化视图（MV）能自动缓存结果，并支持快速刷新。
比如销售日报统计：CREATE MATERIALIZED VIEW mv_daily_sales REFRESH FAST ON COMMIT AS SELECT region, product_type, SUM(amount) FROM sales WHERE sale_date >= TRUNC(SYSDATE) - 30 GROUP BY region, product_type。后续查日报直接查MV，毫秒级返回。
- MV需配合主表上的物化视图日志（
CREATE MATERIALIZED VIEW LOG ON sales）才能启用FAST刷新 - 若数据变更不频繁，用
REFRESH ON DEMAND配合定时任务更省资源 - 注意MV占用额外存储，且查询重写（Query Rewrite）需开启参数
QUERY_REWRITE_ENABLED = TRUE
实际调优时最常被忽略的是执行计划验证——光改SQL不够，必须跑一遍EXPLAIN PLAN FOR ...，重点看Operation是否含SORT GROUP BY或HASH GROUP BY，以及Bytes和Cost是否显著下降。没看执行计划就声称“优化好了”，大概率只是自我安慰。
